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How to Use This Manual 


Before using this manual, use the Workstation Basics and Installation manual 
to install the NetWare Requester for OS/2. 


This manual explains how to configure your network connection for your OS/ 
2 workstation. Follow the chart on Figure 1 on page 2 to determine which parts 
of the manual to use. 


This manual is also accompanied by a quick reference card. This card provides 
an overview of the installation process and a list of all NET.CFG options. 
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Figure 1 How to use this manual 
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migrating from 
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Install your 
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(Workstation Basics 
and Installation) 


yes Read Chapter 1 


To see how NetWare is different under OS/2. 


yes Read Chapter 2 


To see new features for NetWare v4.0. 
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DOS and Windows 
sessions? 


yes Read Chapter 3 


To set up Private and Global NetWare 
connections from virtual sessions. 





Will 
your workstation 
connect to a 
Token-Ring? 


yes Read Chapter 7 


To set up source routing. 
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Information for DOS Users Migrating 
to OS/2 


Topic 





“ODI LAN Drivers” on page 4 

“IPX” on page 4 

“NET.CFG File” on page 5 

“Logging In” on page 5 

“Utilities” on page 6 

“Drive Mappings and Search Drives” on page 6 


“Other Protocols” on page 7 


This chapter explains the basic differences between using NetWare from an 
OS/2 workstation and using NetWare from a DOS workstation. 


For information about OS/2, see the OS/2 Installation Guide or the online 
"Master Help Index." 


After you install the NetWare Requester on your workstation, you can connect 
to a NetWare network and perform basic network tasks. 
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The NetWare Workstation for OS/2 kit also provides the same protocol 
support that the NetWare Workstation for DOS and Windows kit provides: 


+ IPX 

+ SPX 

+ Named Pipes 

+ NetBIOS emulation 


ODI LAN Drivers 


IPX 


ODI LAN drivers used by the Requester serve the same purpose and follow 
the same technical specifications as ODI LAN drivers used by the NetWare 
Workstation for DOS and Windows software. 


OS/2 ODI drivers have the same filenames as DOS ODI drivers, except they 
have a .SYS extension instead of a .COM extension. 


OS/2 ODI drivers are loaded in the CONFIG.SYS file, whereas the DOS ODI 
drivers are loaded in the AUTOEXEC.BAT. (For OS/2, network drivers are 
always loaded in CONFIG.SYS. AUTOEXEC.BAT is not used in OS/2. OS/ 
2 requires all device drivers to be loaded in the CONFIG.SYS. file). 


The NetWare Requester uses the IPX protocol to connect to NetWare servers. 
For OS/2, IPX is a .SYS file and is loaded in the CONFIG.SYS file with the 
other NetWare drivers. 


If you use virtual DOS sessions in OS/2, those sessions use a virtualized 
version of IPX.SYS, called VIPX.SYS. VIPX talks to IPX to allow DOS 
sessions to communicate on the network. In a virtual DOS session, you run 
VIPX provided with the Requester rather than the IPX provided in the 
NetWare Workstation for DOS and Windows kit. 


When you install the NetWare Requester, lines to load IPX and VIPX are 
loaded automatically in CONFIG.SYS. 
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NET.CFG File 


Logging In 


The NET.CFG file serves the same purpose under OS/2 as it does under DOS: 
it allows you to configure your network connection. 


The NET.CFG file for OS/2 has options and settings just as the NET.CFG file 
in DOS does. However, the options and settings are somewhat different. Some 
of them use different syntax and configure different software components. 


Because of this, you cannot just copy a NET.CFG from a DOS workstation to 
an OS/2 workstation and expect it to work. You should instead create a new 
NET.CFG file for the OS/2 workstation (if NET.CFG is required). 


In OS/2, the NET.CFG file is created and edited with the NetWare Requester 
installation program. This program contains online help showing the syntax of 
all options. 


In DOS, the NET.CFG file is created and edited with a text editor. 


You can put both DOS and OS/2 NET.CFG options into the same NET.CFG 
file on your OS/2 workstation. Then, when you run a private virtual DOS 
session, the NetWare Workstation for DOS and Windows software will use the 
DOS options. The NetWare Requester for OS/2 ignores the DOS options. 


When you boot your workstation, the NetWare Requester automatically maps 
drive L: to the SYS:LOGIN directory. This mapping combines with the 
L:\OS2 mapping the Requester installation puts in your path, and gives you a 
search path to the login utilities. You do not have to change to drive L: in order 
to log in. 


The NetWare Requester for OS/2 does not support a LASTDRIVE setting in 
the NET.CFG file. 


You can log in from any OS/2 session or the desktop, and your login applies 
to all other OS/2 sessions. For example, if you logged in from the command 
line of an OS/2 session and then you went to the desktop and used the NetWare 
Tools, you would already be logged in to the location you logged in to at the 
command line. 


NOTE: You cannot login to the network from the NetWare Tools. 


You can also log in to the network from virtual DOS sessions running on 
OS/2. You can set up virtual sessions so that each session can support its own 
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Utilities 


login to the network (private sessions), or so that all sessions—including 
OS/2—share a single login to the network (global sessions). 


Network support from virtual DOS sessions works much the same as network 
support from regular DOS workstations. You will use a NETX.EXE shell and 
a virtualized version of IPX, VIPX.SYS. Chapter 3, “Network Access from 
Virtual DOS and Windows,” on page 19 explains more about setting up virtual 
sessions. 


NOTE: When logging in from virtual sessions, you do not have NetWare Directory 
Services support. This means that you can only log in to a NetWare v4.0 network 
that has bindery emulation. If you boot a DOS session from a real DOS kernel 
instead of the one shipped with OS/2, you can run the NetWare Workstation for 
DOS software and obtain NetWare v4.0 functionality. 


NetWare utilities for OS/2 have the same names as NetWare utilities for DOS. 
However, OS/2 utilities are different executable files than DOS utilities. 


NetWare OS/2 utilities are in the SYS:PUBLIC\OS2 and SYS:LOGIN\OS2 
directories so they do not overlap with NetWare DOS utilities in the 
SYS:PUBLIC and SYS:LOGIN directories. If you run a NetWare DOS utility 
in OS/2, OS/2 will try to start a DOS session to run that utility. 


Because the OS/2 utilities may not be installed on all servers, the NetWare 
Requester installation program copies LOGIN, NLIST, MAP, and CX to the 
\NETWARE directory where the Requester files are located. This allows you 
to access other servers where OS/2 utilities are installed. 


Drive Mappings and Search Drives 


Search drives are not used in OS/2. Instead, the search functionality to the 
NetWare utilities and other programs is set up with PATH, LIBPATH, and 
DPATH statements in the CONFIG.SYS file. The OS/2 Installation Guide 
contains more information about PATH, LIBPATH, and DPATH. 


Mapping to Login Utilities 


When you boot your workstation, the NetWare Requester connects to the first 
server it finds and maps drive L: to the SYS:LOGIN directory. This mapping 
combines with the L:\OS2 mapping the Requester installation puts in your 
path, and gives you a search path to the login utilities. Once you log in, the L: 
mapping disappears. 
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Mapping to Public Utilities 


The NetWare v4.0 default login script for OS/2 contains the following line 
mapping drive P: to the utilities: 


MAP P:=SYS: PUBLIC 


This mapping combines with the P:\OS2 mapping the Requester installation 
puts in your path and gives you a search path to the SYS:PUBLIC\OS2 
directory. When you type a utility name from any drive other than P:, the 
utility from the \OS2 subdirectory will be executed. 


IMPORTANT: Even though your search path gets set to SYS:PUBLIC\OS2 by 
default, your P: drive stays mapped to SYS:PUBLIC. If you change to the P: drive, 
you will be in the SYS:PUBLIC directory, not the SYS:PUBLIC\OS2 subdirectory. If 
you type a utility name while at the P: drive, the DOS version of the utility will be 
executed. 


If you go to drive P: and then change to the \OS2 subdirectory, your search path 
will no longer be valid. Your search path will be expecting to find an \OS2 
subdirectory to the P: drive. Since drive P: will be mapped to SYS:PUBLIC\OS2, 
the OS/2 path command will be looking for a directory with the following name: 


SYS: PUBLIC\0S2\0S2 


Chapter 3, “Creating Login Scripts and Menus,” in Supervising the Network 
and Chapter 4, "Create Login Scripts," in Installation and Upgrade explain 
more about login scripts. 


Other Protocols 
The NetWare Workstation for OS/2 kit provides support for the following 
protocols: 
* SPX 
+ NetBIOS emulation 


+ Named Pipes 


These protocols are used to support OS/2 clients and servers on a distributed 
application network. SPX is also used to support some NetWare printing 
utilities. 


The protocols included with the NetWare Requester can only be run on OS/2 
workstations. Separate programs are provided in the NetWare Workstation for 
DOS and Windows kit to support these protocols on DOS and Windows 
workstations. 
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Named Pipes and NetBIOS on an OS/2 workstation can connect to the DOS 
Named Pipes Extender TSR and NetBIOS.EXE TSR, respectively, running on 
a DOS workstation. 


You can select support for these protocols in the NetWare Requester 
Installation program. The protocols you selected are loaded in the 
CONFIG.SYS file. 


To access SPX, NetBIOS, and Named Pipes support from virtual DOS and 
Windows sessions on OS/2, you must load some programs provided with the 
NetWare Requester. Chapter 9, “Setting Up Named Pipes and NetBIOS 
Protocols,” on page 113 explains more about using protocols from virtual 
DOS and Windows sessions. 
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Information for NetWare v2.x and v3.x 
Users Upgrading to NetWare v4.0 





If you used the NetWare Requester for OS/2 v2.0 with NetWare v3.x and v2.x 
servers, you should be aware of differences in NetWare v4.0. 


Significant changes have been made in the following areas: 





Topic 





“Default Frame Type for Workstation ODI Drivers” on page 9 
“Selecting a Preferred Server” on page 10 

“Logging In to the Network” on page 11 

“Mappings in Default Login Script” on page 12 

“Mapping to the Public Utilities” on page 13 

“Login Scripts” on page 14 


“Virtual DOS and Windows Sessions” on page 15 





Default Frame Type for Workstation ODI Drivers 


The default frame type for Ethernet ODI drivers (such as NE2000.SYS) has 
changed. In NetWare v3.x and NetWare v2.x, Ethernet drivers defaulted to 
Ethernet_802.3. In NetWare v4.0, they default to Ethernet_802.2. 


NetWare v4.0 server drivers for Ethernet also default to Ethernet _802.2. 
Servers and workstations use the same frame type to communicate with each 
other. 
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Routers on the network also have to support the frame type or your 
workstation often will not be able to get a connection. Some routers currently 
in use on your network may not support the new Ethernet_802.2 default. 


IMPORTANT: Your workstation may not be able to connect to a network expecting 
Ethernet_802.3 if you use the Ethernet_802.2 default. 


To eliminate a potential conflict, you can define both frame types 
(Ethernet_802.2 and Ethernet_802.3) on your network. For the workstation, 
define frame types in the NET.CFG file. Include a line similar to the 
following, replacing NE2000 with the name of your ODI driver: 


link driver ne2000 
frame ethernet_802.2 
frame ethernet 802.3 


The first frame defined is the only one used for the initial Get Nearest Server 
request. Therefore, if you have some servers that are using only one frame 
type, such as Ethernet_802.3, put that frame type first. That way your 
workstation will be able to make a default connection to those servers. 


The setting “frame” on page 207 explains more about setting a frame type in 
your NET.CFG file. 


Selecting a Preferred Server 


NetWare v4.0 uses trees and contexts rather than servers to identify what you 
log in to. "NetWare Directory Services" in Concepts explains more about trees 
and contexts. 


A new NET.CFG setting called "preferred tree" has been created. You can use 
"preferred tree" the same way you used "preferred server," except you specify 
a tree name rather than a server name. "Preferred tree" is only for sites that 
have more than one Directory tree. 


For example, to initially connect to a tree called Novell, you would type the 
following lines in your NET.CFG file: 


netware requester 
preferred tree novell 


Chapter 4, "Setting Up Workstations to Log In to the Network," of 
Workstation Basics and Installation explains more about putting the 
"preferred tree" setting in your NET.CFG file. 
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"Preferred server" is still a supported setting; however, the syntax has 
changed. You now type the word server as well as a server name. For example: 


netware requester 
preferred server fsl 


Regardless of what you have in your NET.CFG file, the Requester will first 
try to establish a default connection to an NDS server when you turn your 
machine on. This connection is made to the first directory services server that 
responds to the Requester. 


If the Requester succeeds in connecting to an NDS server, it will then look for 
a preferred tree. Once it connects to a preferred tree, it will check to see if you 
have a preferred server specified. If that server is in the current context, it will 
connect to that server. 


If the Requester cannot connect to a NetWare Directory Services server, it will 
try to establish a default connection to a bindery server. If it connects to a 
bindery server, it will first look for a preferred server, ignoring any preferred 
tree line you have specified. 


Logging In to the Network 


When you log in under NetWare v4.0, you log in to a network rather than a 
server. This means you log in to a location in the Directory (called a context) 
rather than a server on the network. "NetWare Directory Services" in Concepts 
explains more about the Directory. 


Logging In from the OS/2 Command Line 


You use the NetWare v4.0 LOGIN utility to log in from a command line. This 
utility is copied to your hard drive when you install the Requester, and it is also 
located in the SYS:LOGIN\OS2 directory. 


With the LOGIN utility, you can specify a context in the Directory tree. For 
example, to log in to a NetWare v4.0 network, type: 


LOGIN .JOHN.SALES MKTG 
JOHN is the User object. SALES MKTG is the Organization object. 


You can use the NetWare v4.0 LOGIN utility to log in to NetWare v3.11 
servers. Use the same login syntax you used for the NetWare v3.11 utility and 
add the /B option. For example, you would type 


LOGIN SALES MKTG/NANCY /B 
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"Bindery Emulation" and "NetWare Directory Services" in Concepts explain 
more about the bindery and the Directory. Chapter 4, "Setting Up 
Workstations to Log In to the Network," of Workstation Basics and 
Installation explains more setting up a workstation for logging in. Chapter 5, 
"Workstation Login," of Workstation Basics and Installation explains more 
about logging in. 


Logging In from the Desktop 


You should log in from the command line rather than from the OS/2 
"Network" icon on your desktop. 


If you log in from the "Network" icon on your desktop, you will be logged in 
as a bindery emulation client, not a NetWare Directory Services client. Your 
login script will not be run and you will not be authenticated to the Directory. 


The attachment from NetWare Tools is not a login. It does not run a login 
script or disconnect you from previous logins. However, it does authenticate 
you to the Directory. We suggest you log in from the command line before 
using the Attach feature in NetWare Tools. 


Mappings in Default Login Script 


In NetWare v2.x and 3.x, a default login script was executed if you had no 
other login script of any kind. 


In NetWare v4.0, the default login script still exists. Unless the system 
administrator specifies otherwise with a parameter in the system login script, 
it is executed any time a user login script does not exist. In NetWare v4.0, the 
default login script is executed even when a system login script exists. This is 
a change from NetWare v3.x. 


The NetWare v4.0 default login script contains the following line mapping 
drive P: to the utilities: 


MAP P:=SYS:PUBLIC 


This mapping combines with the P:\OS2 mapping the Requester installation 
puts in your path, and gives you a search path to the SYS:PUBLIC\OS2 
directory. When you type a utility name from any drive other than P:, the 
utility from the \OS2 subdirectory will be executed. 


IMPORTANT: Even though your search path gets set to SYS:PUBLIC\OS2 by 
default, your P: drive stays mapped to SYS:PUBLIC. If you change to drive P:, you 
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will be in the SYS:PUBLIC directory, not the SYS:PUBLIC\OS2 subdirectory. If you 
type a utility name while at the P: drive, the DOS version of the utility will be 
executed. 


If you go to drive P: and then change to the \OS2 subdirectory, your search path 
will no longer be valid. Your search path will be expecting to find an \OS2 
subdirectory to the P: drive. Since the P: drive will be mapped to 
SYS:PUBLIC\OS2, the OS/2 path command will be looking for a directory with the 
following name: 


SYS: PUBLIC\O0S2\0S2 


Mapping to the Public Utilities 


Why Drive P: 


When setting up system or user login scripts for OS/2 users, always map drive 
P: to SYS:PUBLIC, as shown: 


MAP P:=SYS: PUBLIC 


Chapter 3, "Creating Login Scripts and Menus," of Supervising the Network 
explains more about mapping drives in login scripts. 


This mapping combines with the P:\OS2 directory the Requester installation 
puts in your path. The combination gives you a search path to the 
SYS:PUBLIC\OS2 directory. 


If you use another mapping besides P:, that mapping will not combine with the 
P:\OS2 directory the Requester automatically puts in your path. In this case, 
you won't have a search path to the utilities. 


When you type a utility name from any drive other than P:, the utility from the 
\OS2 subdirectory will be executed. 


Why SYS:PUBLIC and not SYS:PUBLIC\OS2 


Do not map the P: drive to SYS:PUBLIC\OS2. 


The NetWare utilities for OS/2 need to find language-specific files in the 
parent directory of the directory from which they were executed. For example, 
a utility executed from SYS:PUBLIC\OS2 expects to find an \NLS 
subdirectory in the SYS:PUBLIC directory. 
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If the drive allowing access to the utilities is mapped to SYS:PUBLIC\OS2, 
that directory becomes the root of the drive, since all network drives mapped 
in OS/2 are root drives. This means that OS/2 does not recognize that there is 
a parent directory for the utilities. When the utilities try to locate the \NLS 
subdirectory in their own parent directory, they are returned an error by OS/2, 
and your utility will not run. 


IMPORTANT: If you change to the P: drive, you will be in the SYS:PUBLIC 
directory, not the SYS:PUBLIC\OS2 subdirectory. If you type a utility name while at 
the P: drive, the DOS version of the utility will be executed. 


If you go to drive P: and then change to the \OS2 subdirectory, your search path 
will no longer be valid. Your search path will be expecting to find an \OS2 
subdirectory to the P: drive. Since drive P: will be mapped to SYS:PUBLIC\OS2, 
the OS/2 path command will be looking for a directory with the following name: 


SYS: PUBLIC\O0S2\0S2 


Login Scripts 


You can log in from 
+ An OS/2 session 
¢ A global or private DOS or Windows session 
+ A global session booted from a real DOS kernel and running VSHELL 


+ A private session booted from areal DOS kernel and running the NetWare 
v4.0 DOS Requester 


The following table shows what login script is executed for which type of 
login, and how to edit those login scripts. 





Table 1 How to edit login scripts for each type of session 
If you log in from Login script run How login script is edited 
OS/2 session NetWare v4.0 Login With the NetWare Administrator for OS/2 utility. 
Profile object See Utilities Reference. 





Private DOS/Windows NetWare v3.11 DOS login From a text editor. Edit the 
session script SYS:MAIL\userlD\LOGIN file. 


Or use a NetWare v3.11 utility, such as 
SYSCON. 
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If you log in from Login script run How login script is edited 





Global DOS/Windows NetWare v3.11 DOS login From a text editor. Edit the 








session script SYS:MAIL\user/D\LOGIN file. 
Or use a NetWare v3.11 utility, such as 
SYSCON. 

Global session booted NetWare v3.11 DOS login From a text editor. Edit the 

from real DOS kernel and script SYS:MAIL\user/D\LOGIN file. 

running VSHELL 
Or use a NetWare v3.11 utility, such as 
SYSCON. 

Private session booted NetWare v4.0 Login With the NetWare Administrator for OS/2 utility. 

from real DOS kernel and Profile object See Utilities Reference. 

running v4.0 DOS 

Requester 





Virtual DOS and Windows Sessions 


With the NetWare Requester v2.01, you have full NetWare v3.11 functionality 
from both Private and Global sessions. However, you do not have NetWare 
Directory Services (NetWare v4.0) functionality. 


This means that you can run NetWare v4.0 DOS utilities from a DOS session, 
but you will not have access to NetWare Directory Services. To a NetWare 
v4.0 server, you will appear as a NetWare v3.11 bindery emulation client. 
"Bindery Emulation" in Concepts explains more about bindery emulation 
clients. 


You can obtain NetWare Directory Services functionality by booting from a 
different DOS kernel than the one included with OS/2 and loading the 
NetWare v4.0 DOS Requester software. Boot from a real DOS kernel by using 
the DOS_STARTUP_DRIVE setting. The OS/2 online "Master Help Index" 
explains how to do this. 


Sessions booted from a real DOS kernel can have either private or global 
support. Global sessions booted with a real DOS kernel have NetWare v3.11 
support. Private sessions booted with a real DOS kernel can have NetWare 
v4.0 support if you load the NetWare v4.0 DOS Requester. 


Chapter 3, “Network Access from Virtual DOS and Windows,” on page 19 
explains more about setting up virtual DOS and Windows sessions. 
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Figure 2 on page 17 shows what NetWare functionality you have under all 
types of virtual sessions. 


Changes to Global NetWare Support 


Global support has been enhanced to provide full NetWare v3.11 functionality. 
Applications or utilities that did not run in a Global session with Requester 
v2.0 should run properly under v2.01. 


Changes to Private NetWare Support 


NOTE: The instructions in this section apply to DOS and Windows sessions 
already set up under the NetWare Requester v2.0. For sessions not set up yet, you 
will need to read Chapter 3, “Network Access from Virtual DOS and Windows,” on 
page 19 instead of doing these steps. 


NETX.COM has changed to NETX.EXE. This means you must open the DOS 
Settings Notebook for each session and make the following changes: 


Procedures 


1 For the DOS_VERSION setting, change the line that includes 
NETX.COM to read: 


NETX.EXE,5,00,214 
2 For the DOS FILES setting, change 255 to 214. 
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Figure 2 


NetWare support in DOS/Windows sessions 

















NetWare feature OS/2 Private Global Private Global Private Global 
sessions | Virtual Virtual Virtual Virtual sessions | sessions 
DOS DOS Windows | Windows | usinga | using a 
sessions | sessions | sessions | sessions | real DOS | real DOS 
kernel & | kernel! 
running 
4.0 DOS 
Requester 
Access to NetWare v4.0 No 
as an NDS client 
Access to NetWare Yes 
v3.11 as a bindery client 
Access to NetWare v4.0 No 
network administration 
utilities 
Ability to manage print No 
jobs 
Access to v4.0 NetWare No 
Tools 
Access to NetWare v4.0 No 


electronic documentation 
(ElectroText) 














1. You cannot run the v4.0 DOS Requester on a Global session that uses a real DOS kernel. Your 
NetWare support comes from VSHELL instead. VSHELL is NetWare v3.11-compliant. 


2. Use the NetWare Administrator for OS/2. 


3. Use NETADMIN for DOS. 


4. You can use NetWare v4.0 printing utilities for DOS to manage print jobs form a regular DOS session 
However, you will only be able to see queues that are in the bindery context of NetWare v3.11 server 


objects. 


5. In a DOS session that uses a real DOS kernel, you can use NetWare v4.0 printing utilities for DOS 


with full v4.0 functionality. You will see all queues rather than just bindery context queues. 


6. Use NetWare Tools for OS/2. 


7. Use NETUSER for DOS. 
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Network Access from Virtual DOS and 
Windows 


Topic 





“Cautions for All Types of Sessions” on page 21 

“Customizing Icons for Global Support” on page 22 

“Setting Up Drive Mappings in Global Sessions” on page 25 
“Customizing Icons for Private Support” on page 27 

“Special Instructions for Win-OS2 Icons” on page 31 

“Special Instructions for DOS_STARTUP_DRIVE Sessions” on page 33 


“Disabling Network Support in Virtual Sessions” on page 35 


From a virtual DOS or Windows session, you can have three kinds of NetWare 
support: 


+ Global logins 


All DOS, Windows, and OS/2 sessions set up for global login support 
share a single login to a NetWare server. Drives that are mapped in one 
session apply to the other sessions. A port captured in one session is also 
captured in other sessions. This is useful in environments where the 
number of connections is carefully monitored. 
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¢ Private logins 


All DOS and Windows sessions set up for private login support have their 
own logins to a NetWare server. Drive mappings and port captures from 
one session do not apply to the other sessions. This is useful in 
environments where users need more than one connection to a server and 
where users need logins from DOS or Windows sessions to be separate 
from logins from OS/2 sessions. 


+ No logins. 


Sessions with network support disabled have IPX/SPX support, but no 
NetWare login support. 


Set up NetWare support for virtual DOS and Windows in two ways: 


¢ Set a default type of support (Global, Private, None) that applies to all 
existing DOS and Windows icons, as well as any new icons that are 
created. 


If you choose this default in the NetWare Requester installation program, 
it is automatically loaded in the CONFIG.SYS file. To change the default 
support, run the NetWare Requester installation program and refer to the 
online help. Chapter 3, "Installing a NetWare Workstation," in 
Workstation Basics and Installation explains about running the 
installation. 


+ Customize the type of support for each DOS and Windows icon on your 
desktop. 


All sessions started from the customized icon will have the type of 
support you specify. For instructions on customizing NetWare support per 
icon, see the sections that follow. 


HINT: If you want to set up icons with different kinds of network support, label the 
icons for those sessions something that indicates the type of support. For example, 
you may want to create "Global DOS Full Screen" and "Private DOS Full Screen" 
icons. 
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Cautions for All Types of Sessions 


Version of NetWare Supported 


From a virtual DOS or Windows session, you can access NetWare v3.11 
networks. On these networks, you can receive full NetWare support, just as if 
you were using an actual DOS or Windows workstation. You can also receive 
support for just the IPX, SPX, Named Pipes and NetBIOS protocols. 


NOTE: You cannot access NetWare v4.0 networks from virtual DOS and Windows 
sessions unless those networks support bindery emulation. If a NetWare v4.0 
network supports bindery emulation, your DOS or Windows session will be seen 
as a bindery-based client. 


However, if you are booting a DOS session from a version of DOS other than the 
one shipped with OS/2 (using OS/2's DOS_STARTUP_DRIVE feature), you can 
access NetWare 4.0 networks from that session. See “Special Instructions for 
DOS_STARTUP_DRIVE Sessions” on page 33. 


Accessing the Correct Version of DOS 


Login Issues 


For all virtual sessions you start, the COMSPEC variable must point to the 
correct version of DOS. If you are running the version of DOS included with 
OS/2, set the COMSPEC variable to the following location: 


SET COMSPEC=drive: \0OS2\MDOS\COMMAND.COM 


You can set the COMSPEC variable at the command line or in a login script. 


Replace drive: with the letter of your boot drive. If you are running another 
version of DOS, the COMSPEC variable should point to the location of the 
COMMAND.COM file for that version. 


NetWare login scripts often contain a statement assigning COMSPEC to a 
network drive, so be sure to check—and if necessary, reset—the COMSPEC 
variable in your login script. 


Figure 2 on page 17 shows what login scripts are executed from which type of 
session and how to edit those login scripts. 


Also, when you log out from local drive in a DOS session, the drive for your 
login directory is the last drive (set with DOS_LAST_ DRIVE in DOS 
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Settings) plus one. For example, if your last DOS drive is C:, the drive you see 
after logging out will be drive D:. 


If you log out from a network drive, the drive remains the same. 


Customizing Icons for Global Support 


Prerequisites 
ü Read “Cautions for All Types of Sessions” on page 21. 





Q Make sure network support for virtual sessions is enabled. If not, enable 
it by running the Requester installation program. Chapter 3, "Installing a 
NetWare Workstation," of Workstation Basics and Installation explains 

how to run the Requester installation. Virtual session support is enabled 
by default. 


Procedures 


To set up global NetWare support for an icon, do the following: 


4 Open the "DOS Settings" notebook for the DOS or Windows icon on your 
desktop. 


For more information on opening DOS Settings, see "DOS Settings" in 
the OS/2 online "Master Help Index." Figure 3 shows how to open DOS 
Settings. 


Figure 3 Opening DOS Settings 
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2 Inthe "DOS Settings" Notebook, choose the "Session" tab. 


Figure 4 on page 23 illustrates the "Session" tab page. 
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Figure 4 Choosing the "Session" Tab 
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3 On the "Session" screen, choose the "DOS Settings . . ." button. 


Figure 5 on page 24 illustrates the "DOS Settings" screen. 


Network Access from Virtual DOS and Windows 23 


Figure 5 The DOS Settings Screen 
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4 (Optional) Enable the NetWare CAPTURE feature for the session. 
4a Select "DOS DEVICE" on the "DOS Settings" screen 


Use this setting to keep open a 
communications resource [for 
example, COM1) until the DOS 
session ends. 

















4b Type the following line in the "Value" field: 
drive: \OS2\MDOS\LPTDD.SYS 


Replace drive with the drive letter of your boot drive. You only need 
to add this line if you want to use the NetWare CAPTURE command 
feature from the virtual session. 


NOTE: If you want this device driver to be loaded for every virtual session you 
open, you can load it in the OS/2 CONFIG.SYS file instead of in the "DOS 
Settings" notebook. See the OS/2 online "Master Help Index" for more 
information on loading DOS device drivers. 


5 Specify that all drives are available to NetWare. 
5a Select "DOS LASTDRIVE." 
5b Type Z in the "Value" field. 


This tells NetWare that all drives up through Z are available for use 
in the session. 
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6 Choose Global NetWare support. 
6a Select "NETWARE RESOURCES." 
6b Type GLOBAL in the "Value" field. 


You can also choose "GLOBAL" from the drop-down list box. Every 
session you start from this icon will have global support. 


7 Enable virtual IPX for this session. 
7a Select "VIPX_ ENABLED." 
7b Select "On." 

8 Save and exit "DOS Settings." 


Setting Up Drive Mappings in Global Sessions 


Drive mappings in DOS differ from drive mappings in OS/2. In OS/2, all 
mapped drives function like root drives, so drives mapped in OS/2 sessions 
will show up as root drives in global DOS sessions. Root drives mapped in 
global DOS sessions will show up as root drives in OS/2 sessions. 


Search drive mappings are not used in OS/2. Therefore, search drives mapped 
in global DOS sessions are ignored in OS/2 sessions. Also, search drives 
mapped in one DOS session do not apply to other DOS sessions. To eliminate 
confusion, avoid using search drives in a global environment. Instead, obtain 
the same functionality by setting up your environment as outlined in the 
procedures below. 


Procedures 


4 Decide which drives you want mapped in your global environment. 
Decide which of those drives need to be included in a search path. 


2 Edit your NetWare v4.0 login script (used in OS/2 sessions) and include 
MAP statements for all NetWare drives. 


3 Edit your NetWare v3.11 DOS login script and include MAP ROOT 
statements for all NetWare drives. 


To edit your NetWare v3.11 DOS login script, use a text editor to edit the 
SYS:MAIL\userID\LOGIN file, or use a NetWare v3.11 utility such as 
SYSCON. 
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Use MAP ROOT rather than MAP for consistency between DOS and OS/ 
2 sessions. For easiest maintenance, both login scripts should contain 
identical map statements. 


4 Edit your OS/2 CONFIG.SYS file and include the drive letters you want 
searchable in your PATH statement. 


This path is where OS/2 searches for .EXE, .CMD, and .COM files. For 
example, to include drive H: in the search path, you would add the 
following to your path: 


H:\; 


If needed, you can also include drive letters in the data path statement 
(DPATH). The DPATH statement is where OS/2 searches for 
nonexecutable, non-.DLL files. 


5 Create a DOS.BAT file which includes a path to the same drives you 
included in the CONFIG.SYS file. 


This path is where DOS searches for files. For example, to include drive 
H: in the search path, type the following line in your .BAT file: 


SET PATH=%PATH%;h:\; 


Note that the "%PATH%" appends whatever you type to the directories 
that already exist in the PATH statement. 


You cannot include DPATH statements in the DOS.BAT file. DOS PATH 
statements are limited to 123 characters, so try to map drives to the exact 
directories you need and minimize the number of subdirectories you 
specify. 


6 Run the .BAT file each time you open a DOS global session. 


You can use "Optional Parameters" on the "Settings" notebook. In the 
"Optional Parameters" text entry box, type /K followed by a space and 
the name of the .BAT file. The file will then be executed at the start of 
every session opened from that icon. 


For more information about PATH, DPATH, Settings, or Parameters, see 
the OS/2 online "Master Help Index." 
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Customizing Icons for Private Support 


Prerequisites 
U Read “Cautions for All Types of Sessions” on page 21. 
Q Make sure network support for virtual sessions is enabled. If not, enable 
it by running the Requester installation program. Chapter 3, "Installing a 
NetWare Workstation," of Workstation Basics and Installation explains 
how to run the installation. Virtual session support is enabled by default. 
Procedures 


To set up private NetWare support for an icon, do the following: 


4 Open the "DOS Settings" Notebook for the DOS or Windows icon on 
your desktop. 


For more information on opening DOS Settings, see "DOS Settings" in 
the OS/2 online "Master Help Index." Figure 6 shows how to open DOS 
Settings. 


Figure 6 Opening DOS Settings 
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2 Inthe "DOS Settings" Notebook, choose the "Session" tab. 


Figure 7 on page 28 illustrates the "Session" tab page. 
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Figure 7 Choosing the "Session" Tab 
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3 On the "Session" screen, choose the "DOS Settings . . ." button. 


Figure 8 on page 29 illustrates the "DOS Settings" screen. 
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Figure 8 
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4 (Optional) Enable the NetWare CAPTURE feature for the session. 
4a Select "DOS DEVICE" on the "DOS Settings" screen 





4b Type the following line in the "Value" field: 
drive: \OS2\MDOS\LPTDD.SYS 


Replace drive with the drive letter of your boot drive. You only need 
to add this line if you want to use the NetWare CAPTURE command 
feature from the virtual session. 


NOTE: If you want this device driver to be loaded for every virtual session you 
open, you can load it in the OS/2 CONFIG.SYS file instead of in the "DOS 
Settings" notebook. See the OS/2 online "Master Help Index" for more 
information on loading DOS device drivers. 


5 Specify how many files the session can open simultaneously. 
5a Select "DOS FILES." 
5b Type 214 in the "Value" field. 


6 Specify what drives are available to NetWare. 
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6a Select "DOS LASTDRIVE." 
6b Type a drive letter other than Z in the "Value" field. 


All drives after this letter are available to the private NetWare 
connection in this session. All drives up to this letter are on your local 
hard drive or available for use in a global session. 


7 Specify the correct version of NETX.EXE. 
7a Select "DOS VERSION." 


7b Inthe "Value" field, find the line that specifies the version of NETX 
and replace it with the following line: 


NETX.EXE,5,00,255 
8 Choose Private NetWare support. 
8a Select "NETWARE RESOURCES." 
8b Type PRIVATE in the "Value" field. 


You can also choose "Private" from the drop-down list box. Every 
session you start from this icon will have its own NetWare login. 


9 Enable virtual IPX for this session. 
9a Select "VIPX_ ENABLED." 
9b Select "On." 

10 Save and exit "DOS Settings." 


11 Load the NETX.EXE program in each session where you want to log in 
to the network. 


To load NETX.EXE automatically for every session you start from a 
particular icon, use "Optional Parameters" on the "DOS Settings" 
notebook for that icon. 


In the "Optional Parameters" text entry box, type /K followed by a space, 
the directory path, and the NETX.EXE filename. The file will then be 
executed at the start of every session opened from that icon. For example, 
to load NETX.EXE from the default location, type the following: 


/K C:\NETWARE\NETX .EXE 


For more information about optional parameters, see "Parameters, 
starting programs with" in the OS/2 online Master Help Index. 
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To load NETX.EXE automatically for all DOS and Windows sessions, 
put the following command in an AUTOEXEC.BAT file in the root of 
your boot drive: 


drive: \path\NETX.EXE 


Replace drive and path with the location of your NETX.EXE file. By 
default, NETX.EXE is installed in \NETWARE with the Requester files. 


NOTE: If you want IPX/SPX-only support, don't load NETX. If you don't load 
NETX.EXE, you will not be able to log in to a NetWare network, but DOS and 
Windows applications will be able to use the IPX protocol. 


Special Instructions for Win-OS2 Icons 


These instructions apply to the Windows 3.0 support that was shipped with 
OS/2 v2.0. 


Prerequisites 
ü Read “Cautions for All Types of Sessions” on page 21. 


OQ) Complete“Customizing Icons for Global Support” on page 22 or 
“Customizing Icons for Private Support” on page 27 for the Win-OS2 
icon. 


Procedures 
You need several additional files for Win-OS2 NetWare support: 


NWIPXSPX.DLL 
NETWARE.DRV 
TBMI2.COM 
NWPOPUP.EXE 
NETWARE.HLP 


By default, these files are copied to the \OS2\MDOS\WINOS2\SYSTEM 
directory on your boot drive when you install the NetWare Requester. 


The TBMI2 file must be loaded before you run any Windows programs that 
make IPX or SPX calls. We recommend loading it before you run any 
Windows programs. 
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To load TBMI2 automatically for all sessions started from a single icon: 
4 Make and use a copy of a DOS icon. 
2 Create a batch file (BAT extension) with the following lines: 


drive: \OS2\MDOS\WINOS2\SYSTEM\TBMI2 .COM 
WINOS2 . COM 
EXIT 


Replace drive with the letter of your boot drive. 

3 Save the batch file in the following directory: 
\OS2\MDOS\WINOS2\SYSTEM 

4 Open the "Settings" for the icon. 

5 Choose the "Program" tab. 

6 In the "Optional Parameters" field, type the following line: 
/K drive: \0S2\MDOS\WINOS2\batchfile.bat 


Replace drive with the letter of your boot drive. Replace batchfile with the 
name of your batch file. 


7 Choose the "Session" tab. 
8 Make sure "DOS Full Screen" is selected. 
Each time you choose this icon, TBMI2 is loaded and Win-OS2 is started. 


For more information about optional parameters, see "Parameters, 
starting programs with" in the OS/2 online "Master Help Index." 


To load TBMI2.COM automatically for all DOS and Windows sessions, 
put the following command in an AUTOEXEC.BAT file in the root of 
your boot drive: 


drive: \OS2\MDOS\WINOS2\SYSTEM\TBMI2.COM 


Replace drive with the letter of your boot drive. 
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Special Instructions for DOS_STARTUP_DRIVE 


Sessions 


If you want to boot a version of DOS other than what shipped with OS/2, refer 
to the OS/2 online "Master Help Index," which explains more about the 
DOS_STARTUP_DRIVE feature. 


If you are using DOS_STARTUP_DRIVE to boot a session, you can have 
global or private NetWare support, just as from a regular virtual session. 


However, in a private DOS_STARTUP_DRIVE session, you can also run the 
NetWare v4.0 DOS Requester and have NetWare v4.0 support. From this kind 
of DOS session, you can log in as a NetWare v4.0 DOS client. 


If you do not want to load (or do not have) NetWare v4.0 Workstation for DOS 
software, you should still load NETX.EXE, shipped with the Requester. In this 
case, you will have the same limitation of being only a NetWare v3.11 client 
as you would have from a session booted from the DOS shipped with OS/2. 


The following sections explain how to set up DOS_STARTUP_DRIVE 
sessions globally or privately. 


Setting up Global DOS_STARTUP_DRIVE Sessions 


Prerequisites 


ü Read “Cautions for All Types of Sessions” on page 21. 





Q Set up your session to boot from another version of DOS. This involves 
creating a boot image file, setting DOS STARTUP_DRIVE, and certain 
other tasks using the VMDISK utilitly. See the OS/2 online "Master Help 
Index." 


QO) Make sure network support for virtual sessions is enabled. If not, enable 
it by running the Requester installation program. Chapter 3 "Installing a 
NetWare Workstation," of Workstation Basics and Installation explains 
how to run the installation program. Virtual session support is enabled by 
default. 


Q) Set up your session for global NetWare support by following the 
instructions in “Customizing Icons for Global Support” on page 22 and 
“Setting Up Drive Mappings in Global Sessions” on page 25. 
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Procedures 


Type the following lines in the CONFIG.SYS file on the DOS diskette or 
partition you will boot from: 


device=drive: \os2\mdos\fsfilter.sys 
device=drive:path\dosvshll.sys 
device=drive: path\dosvipx.sys 
lastdrive=z 


Replace drive and path with the drive and path names where the NetWare 
Requester files are located. 


Type the /astdrive line only if you want the last global drive to be something 
different than the last drive in use by OS/2 at the time you start the virtual 
session. 


Setting Up Private DOS_STARTUP_DRIVE Sessions 


Prerequisites 
ü Read “Cautions for All Types of Sessions” on page 21. 


Q) Set up your session to boot from another version of DOS. This involves 
creating a boot image file, setting DOS _STARTUP_DRIVE, and certain 
other tasks using the VMDISK utilitly. See the OS/2 online "Master Help 
Index." 


Q Make sure network support for virtual sessions is enabled. If not, enable 
it by running the Requester installation program. Chapter 3, "Installing a 
NetWare Workstation," of Workstation Basics and Installation explains 
how to run the Requester installation. Virtual session support is enabled 
by default. 


0 Set up your session for private NetWare support by following the 
instructions in “Customizing Icons for Private Support” on page 27. 


Procedures 


1 Type the following lines in the CONFIG.SYS file on the DOS diskette or 
partition you will boot from: 


device=drive:\os2\mdos\fsfilter.sys 
device=drive: path\dosvipx.sys 
files=214 

lastdrive=letter 
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Replace drive: and path with the drive and path names where the NetWare 
Requester files are located. Replace letter with the last local drive 
accessible to the session. NetWare drives start after this letter. 


The FSFILTER.SYS driver provided by OS/2 gives the 
DOS_STARTUP_DRIVE session access to OS/2 HPFS drives and 
Named Pipes support. See the OS/2 documentation for more information 
about FSFILTER.SYS. 


2 Load the NetWare Workstation for DOS software. 


2a To load NetWare v4.0 DOS Requester, follow the directions in 
NetWare Workstation for DOS and Windows. Use the software on 
the DOS Requester diskette, WSDOS_1/. 


2b To load NETX.EXE for NetWare v3.11 support, follow the 
instructions in Step 11 on page 30. Use the software on the OS/2 
Requester diskette, WSOS2_1. 


Any network drives mapped in an OS/2 session will show up as local drives 
in a private DOS _STARTUP_DRIVE session. 


Disabling Network Support in Virtual Sessions 


To disable all network support, run the NetWare Requester installation 
program and deselect "Support for DOS and Windows Sessions." Then reboot 
your machine. This keeps VIPX.SYS and VSHELL.SYS from loading. 


To reenable support, run the install and select "Support for DOS and Windows 
Sessions." 


Chapter 3, "Installing a NetWare Workstation," in Workstation Basics and 
Installation explains how to run the Requester installation program. 


For a technical diagram of NetWare support in a virtual DOS/Windows 
session, see Appendix C, “Architecture Diagrams,” on page 247. 
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How to Configure Your Workstation 


Topic 





“When Is Configuration Required” on page 37 
“Procedures” on page 39 
“NET.CFG Format Requirements” on page 42 


“Quick Reference List of NET.CFG Options” on page 43 


This chapter contains instructions for configuring the NetWare Requester for 
OS/2 v2.01. 


Complete information for the configuration options is found in the help 
screens in the NetWare Requester installation program, and in Appendix B, 
“NET.CFG Options Reference,” on page 201. 


When Is Configuration Required 


Table 2 


Read the table below to decide if you must configure the workstation before 
the NetWare Requester will run. 


Situations when configuration is required 





You must configure if For information, go to 
Your workstation has more Chapter 5, “Network Boards and Drivers,” on 
than one network board page 47 
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You must configure if 


For information, go to 





Your workstation has a single 
board, but the board is not 


using the factory default 
settings 


Chapter 5, “Network Boards and Drivers,” on 
page 47 





Your network uses an Ethernet 


frame type other than 
Ethernet_802.2 


Chapter 5, “Network Boards and Drivers,” on 
page 47 





The NetWare Requester will 
share a network board with 


other software 


Chapter 8, “Sharing a Network Board with IBM 
Software,” on page 73 





Configuration may be useful in other circumstances shown in the table below. 
These circumstances are described in detail in the remaining chapters of this 


manual. 


Table 3 Other situations when configuration might be useful 





You may want to configure if 


For information, go to 





You want to change the default 
packet signature security level 


Chapter 6, “Improving Speed and Security,” on 
page 59 





You want to turn off Packet 
Burst or Large Internet Packet 


transmissions 


Chapter 6, “Improving Speed and Security,” on 
page 59 





Your workstation will connect 
to a Token-Ring network using 


Source Routing 


Chapter 7, “Using OS/2 Workstations on a 
Token-Ring Network,” on page 67 





Your workstation will need to 
use the NetBIOS or Named 


Pipes protocols 


Chapter 9, “Setting Up Named Pipes and 
NetBIOS Protocols,” on page 113 





Your want your workstation to 
connect to a preferred server 


The “preferred server” on page 230 and the 
“preferred tree” on page 231 





You are setting up remote 


booting workstations 


Chapter 11, “Remote-Booting OS/2 
Workstations,” on page 157 





38 NetWare Workstation for OS/2 v2.01 


Procedures 


Configuration options for the NetWare Requester are stored in the NET.CFG 
file. When you start up your workstation, the NetWare Requester searches for 
NET.CFG in the directories specified in the DPATH line in the CONFIG.SYS 
file. If the Requester does not find a NET.CFG file, it starts up using the 
default configuration values built into the Requester. 


The NET.CFG file is located in the root directory of your boot drive. If you 
have previously configured the Requester, a NET.CFG file already exists for 
your workstation. Change the current configuration by modifying and saving 
the existing file. 


Reinstalling the NetWare Requester will not overwrite an existing NET.CFG 
file; instead, the existing NET.CFG file will appear in the installation program 
for you to edit. 


If you have not configured the Requester before, a NET.CFG file does not 
exist for your workstation. You must create this file in order to configure the 
Requester. 


To create or edit NET.CFG, you can use either of the following: 


+ The NetWare Requester installation program. Use the online help in the 
program to determine what to include in the file. 


+ A text editor. Use the format requirements in this chapter and the 
reference pages in Appendix B, “NET.CFG Options Reference,” on page 
201 to determine what to include in the file. 


To edit or create NET.CFG with the installation program: 
1 Start the NetWare Requester installation program. 


Choose the "Installation" icon in the "Novell" group window on your 
desktop or insert the WSOS2_1 diskette and type INSTALL at a command 
prompt. The "NetWare Requester for OS/2 Installation Utility" window 
appears. 


2 Select "This workstation. . ." from the "Configuration" menu. 
The "Edit NET.CFG File for This Workstation" window appears. 

3 Check the location of the NET.CFG file. Change the location if you want. 
Use the online help if necessary. 


4 Type the NET.CFG options you want in the "Current NET.CFG File 
Contents" box. 
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See Figure 9 on page 41 for an explanation of how to edit the NET.CFG 
file. Read the NET.CFG format requirements from the online help or from 
the next section. 


You can cut and and paste text from the help window at the bottom of the 
screen to the "Current NET.CFG File Contents" window. Use the 
following keys: 


Table 4 Key definitions for the NET.CFG window 


To do this Use these keys 





Highlight text Click and drag with the mouse, or move the 
cursor with the arrow keys while holding down 
the <Shift> key 





Copy text <Ctrl><Insert> 





Cut text (text willreappearthe <Shift><Delete> 
next time you refresh the 








window) 
Paste text <Shift><Insert> 
Delete text (deleted text <Ctrl><Delete> 


cannot be pasted) 
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Figure 9 How to edit the NET.CFG file 





















aa Type NET.CFG 
options and 
settings here. 


Select a 
NET.CFG option, 
setting, or topic. 


Save your 
configuration or 
change your mind. 









| Edit: 


he NET.CFG file for this worksfation 
NET.CFG Options Current NET.CFG File Contents 


abort timeout netware requester 
listen timeout preferred server sales 
verify timeout 
send timeout 
sessions 
NetYYare Requester 
cache buffers 
nonded server 
request retries 
sessions 


NetYYare NetBIOS 
abort timeout 


PREFERRED SERVER servername 
Usage 


Replace "servername" with the name of a NetY/are server. 


Default: none. 






















EZ Select the type 
of information you 
want to see. 


PA Read online 
help for the topic 
you selected. 






5 To save your changes to NET.CFG, choose "Save." 


6 To exit the installation program, double-click in the upper left corner of 
the main window. 


7 Use OS/2's "Shutdown" feature to reboot your workstation. 


Installation and configuration changes will not take effect until you 
reboot. 
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NET.CFG Format Requirements 


Each NET.CFG option has several settings. In this chapter, these settings are 
alphabetized under the option to which they apply. Options and settings do not 
have to be alphabetized in the NET.CFG file. 

Use the following rules to create or modify a NET.CFG file: 


+ Type options at the left margin of the file with no spaces before or after 
them. Options are not case-sensitive. 


+ Type one option per line. 


+ Type settings, one per line, on the lines following the option to which they 
apply. When editing the NET.CFG from the installation program, use the 
Space bar rather than the <Tab> key to indent these settings. The <Tab> 
key moves to the next field on the screen. Indent settings at least one 
space. Settings are not case sensitive. 


¢ Place a hard return at the end of every line in the file, including the last 
line. Blank lines are not necessary and are ignored. 


WARNING: If you don't put a return at the end of the last line, the line will be 
ignored. 


+ Precede comments with a semicolon. 


Figure 10 on page 43 illustrates NET.CFG format. 
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Figure 10 NET.CFG format 


Options typed flush 


left, one per line. 





—* 





L__e 


link driver ne2000 Settings indented 
under option, one 





int 4 i setting per line. 
port 360 


frame ethernet_802.3 — 
link driver ne1000 
int 5 
port 310 
node address 02608c861759 
protocol stack spx 
sessions 256 
netware requester 
preferred server sales 
named pipes ° Hard return and 
client sessions 16 line feed after all 


server sessions 255 = 
service threads 32 *—— 








lines, including the 
last line. 





Quick Reference List of NET.CFG Options 


How to Configure Your Workstation 








Figure 11 on page 44 and Figure 12 on page 45 list all NET.CFG options and 
settings, as well as the default value for each option or setting. More detailed 
information is in Appendix B, “NET.CFG Options Reference,” on page 201. 
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Figure 11 NET.CFG quick reference 


NetWare Configuration Options 
Options and Settings Defaults 








daemon configuration 
message timeout number 


displayharderrors no 

link driver name 
dma [index] channel [#1], set by driver 
frame name set by driver 
int [index] irq [#1], set by driver 
mem [index] starting_adadress [size].. [#1], set by driver, [set by driver] 
node address number. preset on board 
port /index] starting_port [number] ... [#1], set by driver, [set by driver] 
protocol name id frame IPX, 0, Ethernet_802.2 
SIOE? hrs T tines olbhag is om ade dae Oak bueean cate slot ? 
slot number 


link support 


buffers number [buffer_size] 


named pipes 


client sessions number 
server sessions number 
service threads number 


netware netbios 


abort timeout number 

broadcast count number internet on:4, internet off:2 
broadcast delay number internet on:2,000, internet off:1,000 
commands number 

internet [on/off] 

listen timeout number 

names number 

retry count number 
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Figure 12 NET.CFG quick reference (cont’d.) 


NetWare Configuration Options (continued) 
Options and Settings Defaults 








retry delay number 
sessions number 
verify timeout number 


netware requester 
cache buffers number 
large internet packets off 
name context context 
packet burst off 
preferred server servername 
preferred tree treename 
request retries number 
sessions number 


protocol odinsup 


bind driver [number] 


protocol stack ipx 


protocol stack spx 


abort timeout number 
listen timeout number 
retry count number 
send timeout number 
sessions number 


protocol route 
source route def gbr mbr nodes n board n 
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Network Boards and Drivers 


This chapter explains network board and driver issues. For basic information 
about boards and drivers, see the documentation for your network board. 


Topic 





“Matching Driver Settings with Board Settings” on page 47 
“Specifying Frame Types for a Driver’ on page 48 
“Why Have More Than One Network Board” on page 51 


“Setting Up Two Network Boards” on page 53 





Matching Driver Settings with Board Settings 


Network boards come with factory defaults for such hardware settings as: 
+ Direct memory access channel (DMA) 
+ Interrupt line IRQ) 
+ Input/output port 
+ Memory range 


+ Node address 


These factory defaults can usually be changed by moving jumpers or setting 
switches. 


The NetWare Requester for OS/2 expects each board to be using the default 
settings. Therefore, if you change the factory default for any of the hardware 
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settings listed above, you must tell the OS/2 ODI driver what the new setting 
is. 


To do this, use the "Link Driver" option in the NET.CFG file. The "Link 
Driver" option allows you to set the following hardware-related settings: 


link driver name 
dma [index] channel 
int [index] irq 
mem [index] starting address [size] 
node address number 
port [index] starting port [number] 


Chapter 4, “How to Configure Your Workstation,” on page 37 explains more 
about putting options in the NET.CFG file. “Link Driver” on page 205 
explains more about using these settings. 


Shortcut for EISA and Micro Channel Boards 


If you are using an EISA or Micro Channel board, you do not have to specify 
the hardware settings shown above. The OS/2 ODI driver scans the board and 
automatically determines what settings are in use. 


You just have to tell the NetWare Requester what slot the network board you're 
using is in, or tell it to scan all slots. Do this with the "Link Driver" option and 
the "slot" setting in the NET.CFG file: 


link driver name 
slot number 


Replace number with the number of the slot, or replace number with a 
question mark to tell the Requester to scan all slots. The section “slot” on page 
215 explains more about using the "slot" setting. 


Specifying Frame Types for a Driver 


All communications on a network consist of packets of information being sent 
between computers. 


There are different kinds of packets, distinguished from each other mainly by 
the order of the information in the packet. Each kind of packet follows its own 
set of rules. This set of rules is called a frame type. 


When a computer sends and receives a particular kind of packet, then that 
computer is transmitting with that particular frame type. 
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Table 5 


By default, each network driver uses only one kind of frame type. However, 
most drivers also support other frame types. For example, an NE2000 driver 
supports Ethernet_802.2, Ethernet_802.3, Ethernet_II, and Ethernet_SNAP. 


The following table lists some common network boards and the frame types 
supported by each. This list is not comprehensive. 


List of frame types and drivers 














Frame type Network board driver 

Ethernet_802.3 NE1000, NE2000, NE2100, NE2, NE2-32, 3C501, 
3C503, 3C505, 3C523, EXOS205, EXOS215, 
ODINSUP 

Ethernet_802.2 NE1000, NE2000, NE2100, NE2, NE2-32, 3C501, 
3C503, EXOS205, EXOS215, ODINSUP, LANSUP 

Ethernet_ll NE1000, NE2000, NE2100, NE2, NE2-32, 3C501, 
3C503, 3C505, 3C523, EXOS205, EXOS215, 
ODINSUP 

Ethernet_SNAP NE1000, NE2000, NE2100, NE2, NE2-32, 3C501, 


3C503, EXOS205, EXOS215, ODINSUP. LANSUP 





Token-Ring ODINSUP, TOKEN, LANSUP 





Token-Ring_SNAP ODINSUP, TOKEN, LANSUP 











IBM_pcn2_802.2 PCN2, PCN2L, LANSUP 
IBM_pcn2_snap PCN2, PCN2L, LANSUP 
Novell_rx-net TRXNET, TRXNET2 


You can use the "Link Driver" option in the NET.CFG file to tell the driver 
what frames types you want used. You can only specify frame types supported 
by that driver. 


link driver name 
frame name 


Replace name with the name of the frame type. To specify more than one 
frame type, you can type additional frame type lines. 
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Chapter 4, “How to Configure Your Workstation,” on page 37 explains more 
about how to put options in the NET.CFG file. The section “frame” on page 
207 explains more about using the "frame" setting. 


Cautions When Changing Frame Type 


The default frame type for Ethernet ODI drivers has changed. In NetWare v2.x 
and NetWare v3.x, Ethernet drivers defaulted to Ethernet_802.3. In NetWare 
v4.0, they default to Ethernet_802.2. 


NetWare v4.0 server drivers for Ethernet also default to Ethernet _ 802.2. 
Servers and workstations must use the same frame types to communicate with 
each other. 


Routers on the network also have to support the frame types or your 
workstation often will not be able to get a connection. Some routers currently 
in use on your network may not support the new Ethernet_802.2 default. 


IMPORTANT: Your workstation may not be able to connect to a network expecting 
the old default if you use the new Ethernet_802.2 default. 


To eliminate potential conflict, you can define both frame types 
(Ethernet_802.2 and Ethernet_802.3) on your network. For the workstation, 
define frame types in the NET.CFG file. Include a line similar to the 
following, replacing ne2000 with the name of your ODI driver: 


link driver ne2000 
frame ethernet_802.3 
frame ethernet_802.2 


The first frame defined is the only one used for the initial Get Nearest Server 
request. Therefore, if you have some servers that are using only one frame 
type, such as Ethernet_802.3, put that frame type first. That way your 
workstation will be able to make a default connection to those servers. 


The section “frame” on page 207 explains more about setting a frame type in 
your NET.CFG file. 
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Why Have More Than One Network Board 


When using the NetWare Requester, there are only two conditions where you 
benefit from having more than one network board in your computer: 


+ When each board supports a different communications software package. 


+ When each board is connected to a physically separate network, but those 
networks are connected with one or more routers. 


In this case, a second board may be useful. Additional boards after the 
second will be completely ignored. 


IMPORTANT: If you have two network boards, you must be aware of some 
configuration issues, discussed in the following sections. 


Two or More Communications Packages 


You may want to use two or more network boards when each board supports 
its own communications software package. 


For instance, you may want to have Communications Manager use one board 
and NetWare Requester use another. Or you may want NetWare for OS/2 to 
use one board and for NetWare Requester to use another. 


In these cases, each package provides the driver for its own board, and the 
setup for NetWare Requester is just as if only one board existed. There are no 
additional steps to set up the second board, since that board is entirely 
controlled by the other communications package. 


NOTE: In most cases, the NetWare Requester can share a board with other 
communication packages so that you do not need to purchase two boards. To have 
the NetWare Requester share a board with Extended Services or LAN Services, 
see Chapter 8, “Sharing a Network Board with IBM Software,” on page 73. To have 
NetWare Requester share a board with NetWare for OS/2, see NetWare v4.0 
Installation Supplement for OS/2 Servers. 


Two Connected Networks 


You may want to use two network boards when each board is connected to a 
physically separate network, but those networks are connected with one or 
more routers. 


If your two networks are physically connected, your second board may serve 
as a backup route if the connection to your first board fails. 


If the networks are not physically connected, the second board will not be able 
to act as a backup. 
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Why Do the Networks Have to Be Connected 


When the workstation boots, the IPX protocol binds to all network boards that 
have OS/2 ODI drivers loaded. Whenever IPX needs to find a new destination 
on the network, it queries the network for possible routes to that destination. 


IPX only sends out a destination query on the primary network board. It never 
queries the secondary (or other) board for a route. 


If IPX does not find the destination using the primary board, you see a 
connection error, even if the destination could be found if IPX were to use the 
second board. 


IMPORTANT: If each board is connected to a physically separate network, 
destinations on the second board's network will never be found. Only destinations 
on the first board's network will be locatable. 


How is The Second Board a Backup 


Once IPX finds a destination using the primary network board, it stores the 
route to that destination in a router table and makes the connection. 


After the connection is made, IPX checks all networks that are connected to 
that destination for any other possible routes from your OS/2 workstation to 
the destination. 


If it finds a secondary route, IPX rebuilds the router tables and stores that 
route. If the primary connection fails, IPX will use the secondary route to 
continue transmissions to that destination. 


IMPORTANT: The destination always has to be available initially from the primary 
board. However, once the destination is found through the primary board and the 
connection is made, a route from the secondary board may be used to continue 
transmission if the primary connection fails. 


What Happens If the Primary Connection Is Broken 


If IPX is using a route through the second board, the primary connection can 
be broken without causing the secondary connection to fail. 


However, the secondary board does not ever become the primary board even 
when the primary board fails. This means that if IPX needs to find a new 
destination while the primary connection is down, it will not be able to query 
for the destination, since queries are only sent on the primary board. 


IMPORTANT: To allow IPX to find new destinations, you will have to restore the 
primary connection. 
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Setting Up Two Network Boards 


If you have two network boards in your computer, you may need to 


+ 


+ 


+ 


Load an additional ODI driver. See “Loading the Driver for an Additional 
Board” on page 53. 


Change which board IPX uses as primary. See “Changing Which Board 
Is Primary” on page 54. 


Define hardware settings and frame type for each board. See “Setting 
Hardware Settings and Frame Type for Each Board” on page 57. 


Loading the Driver for an Additional Board 


Prerequisite 


Procedures 


The NetWare Requester installation program allows you to specify an ODI 
driver. That driver is then loaded automatically in the CONFIG.SYS file. 


You may need to load an additional ODI driver manually in the CONFIG.SYS 
file if 


+ 


+ 


You have two network boards, and 
Those boards use different ODI drivers. 


IMPORTANT: If the boards use the same ODI driver (for example, two NE2000 
boards), simply load the driver once when you install the Requester, then go to 
“Specifying Primary with Two Boards of the Same Type” on page 55. Do not 
complete the steps in this section. 


Install the NetWare Requester with one of the ODI drivers. It does not 
matter which one. Chapter 3, "Installing a NetWare Workstation," in 
Workstation Basics and Installation explains how to install the Requester. 


Open the CONFIG.SYS file in a text editor. 


For example, to use the OS/2 System Editor at the OS/2 command line, 
type: 

E C:\CONFIG.SYS 

CONFIG.SYS is generally located in the root of your boot drive. 


In the NetWare Requester lines, find the line loading the first ODI driver. 
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For a list of common ODI drivers, see Table 5, “List of frame types and 
drivers,” on page 49. 


3 Decide which driver you want IPX to recognize as primary. 


The driver for the primary board is the only one IPX uses to query the 
network for a route. The driver for the secondary board is never queried. 
“Why Have More Than One Network Board” on page 51 explains more 
about primary and secondary boards. 


4 Type new line to load an additional driver. 


To load a driver as primary, type the line above the existing driver line. To 
load a driver as secondary, type the line below the existing line. 


The first driver loaded in the CONFIG.SYS file is the primary driver. You 
can also specify a primary driver with the "Protocol Stack IPX bind" 
setting in the NET.CFG file. 


Type the correct path to the driver in the line. If you are using a Novell- 
supplied driver, the driver is located where your other Requester files 
were installed, usually in C:\NETWARE. 


For example, to load an NE2000 driver from the default location, type the 
following: 


C:\NETWARE\NE2000.SYS 


NOTE: If you have two boards using the same driver name (such as two NE1000 
boards), do not load the driver twice. 


5 Save and exit the CONFIG.SYS file. 


6 Reboot your machine to load the additional drivers. 


Changing Which Board Is Primary 
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The board whose driver loads first in the CONFIG.SYS file is the primary 
board. You can change which board is primary by 


+ Reordering drivers in the CONFIG.SYS file. 


The previous section, “Loading the Driver for an Additional Board” on 
page 53, explains how to edit the CONFIG.SYS file. 


+ Using a NET.CFG option to bind IPX to a different driver. 


To change which board IPX views as primary, use the "Protocol Stack IPX" 
option in the NET.CFG file: 


protocol stack ipx 
bind drivername 
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Replace drivername with the name of the driver that controls the board, and 
indent the "Bind" setting. For example, to set a Token-Ring board as primary, 


type: 


protocol stack ipx 
bind token 


“Protocol Stack IPX” on page 236 explains more about using this option. 


Specifying Primary with Two Boards of the Same Type 


If you have two boards using the same type of ODI driver (such as two 
NE2000 boards), do not load the same driver twice in the CONFIG.SYS file 
and do not specify a "Protocol Stack IPX" option. 


Instead, use the "Link Driver" option in the NET.CFG file to specify that the 
driver is used twice. Do this by placing two "Link Driver" sections in your 
NET.CFG file, each one specifying the driver name and the hardware settings 
used by that board. 


The hardware settings for at least one of the boards must be specified, since 
you cannot have two boards of the same type both using the default hardware 
settings. 


“Matching Driver Settings with Board Settings” on page 47 explains more 
about specifying hardware settings with the "Link Driver" option. 


For example, if you have two NE2000 boards, you may include the following 
lines in your NET.CFG file: 


link driver ne2000 
frame ethernet_802.3 
frame ethernet_802.2 
int 5 
port 360 

link driver ne2000 
frame ethernet_802.3 
frame ethernet_802.2 
int 4 
port 320 


Putting two occurrences of "link driver ne2000" loads the NE2000 driver 
twice. If you do not specify two "Link Driver" sections, a driver will not be 
loaded for the second board, and the second board will be ignored entirely. 


IMPORTANT: The board whose line comes first in the NET.CFG file is the one IPX 
uses as primary. 
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Shortcut for Multiple EISA and Micro Channel Boards 


If you are using two EISA or Micro Channel boards that use the same driver 
(such as NE3200 or 3C523), you still must specify a "Link Driver" section for 
each board. 


However, instead of specifying the hardware settings used on the board, you 
can specify the "slot" setting. The "slot" setting tells the ODI driver which slot 
a network board is in. The driver then scans the board and automatically 
determines what hardware settings are in use. 


For example, for two NE3200 boards, type: 


link driver ne3200 
frame ethernet_802. 
frame ethernet_802. 
slot 2 

link driver ne3200 
frame ethernet_802. 
frame ethernet _802. 
slot 1 


N w 


N w 


In this example, the board in slot 2 becomes the primary board because the 
driver for it was loaded first. 


To change which board is primary, reorder the "Link Driver" sections. For 
example, to set the board in slot 1 as primary, type: 


link driver ne3200 
frame ethernet_802. 
frame ethernet_802. 
slot 1 

link driver ne3200 
frame ethernet_802. 
frame ethernet_802. 
slot 2 


N w 


N w 


The section “slot” on page 215 explains more. 


Why Change Which Board Is Primary 


There are two scenarios in which you may want to change which board is 
primary. 


Scenario 1: Faster queries on networks connected with a router 


Suppose your primary board is attached to a network and your secondary 
board is attached to a network. The two networks are connected with a router. 
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Because of the router, IPX can reach a destination on the second network by 
going through the first network, then the router, and then the second network. 


However, IPX may have been able to find the destination faster if it was 
querying from the second network board rather than the first. In this case, you 
may want to use the NET.CFG option to change the secondary board to 
primary and have IPX use it for queries. 


If you did this, queries would not be sent on the former primary board. 


Scenario 2: Switching the board in use on unconnected networks 


Suppose you have two network boards, each connected to a physically 
separate network. Since IPX only queries the primary board, you will only 
have access to the first network unless you change which board is primary. 


In this case, you may want to change the NET.CFG option and reboot 
whenever you want to access the other network. 


Or it may be easier to 
+ Unplug your cable from one board and connect it to the other board, or 


+ Connect the networks with a router 


Setting Hardware Settings and Frame Type for Each Board 


The requirements for setting hardware settings and frame type in the 
NET.CFG file are the same whether you have one board or two boards. 


The only difference is if you have more than one board, you may need to 
specify a "Link Driver" section for each board. 


To see how to set hardware settings or frame type using "Link Driver," see 
“Matching Driver Settings with Board Settings” on page 47 and “Specifying 
Frame Types for a Driver” on page 48. 


For example, if you have an NE2000 and a Token-Ring board, you might type 


link driver ne2000 
frame ethernet_802.3 
frame ethernet_802.2 
int 5 
port 360 

link driver token 
frame token-ring 
frame token-ring_ snap 
slot 2 
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If you have two boards with the same driver name (such as NE2000), see 
“Specifying Primary with Two Boards of the Same Type” on page 55 for 
information about using the "Link Driver" option. 


58 NetWare Workstation for OS/2 v2.01 





Improving Speed and Security 


Topic 





“Improving Speed with Packet Burst” on page 59 
“Improving Speed by Using Large Internet Packets” on page 60 


“Improving Security by Using Packet Signature” on page 61 





You can use three features to improve speed and security on your network: 
¢ Packet Burst 
¢ Large Internet Packets 


¢ Packet Signature Level 


Improving Speed with Packet Burst 


Packet Burst is a protocol that speeds the transfer of multiple-packet NCP 
reads and writes. Packet Burst eliminates the need to sequence and 
acknowledge each packet. With Packet Burst, the server or client sends a 
whole set (or burst) of packets before it requires an acknowledgment. 


Packet Burst reduces network traffic by allowing multiple packets to be 
acknowledged. Packet Burst also monitors dropped packets and retransmits 
only the missing packets. 


At connection time, maximum burst sizes are negotiated with each server. 
Since Packet Burst is established with each connection, it's possible to "burst" 
with one server but not with another. 
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Once you establish a Packet Burst connection between a workstation and a 
server, the workstation automatically uses Packet Burst whenever an 
application requests to write more than three times the maximum packet size 
of data. This means that an application doesn't have to be aware of Packet 
Burst. 


Disabling Packet Burst 


Packet Burst is enabled at the workstation by default. You can disable it by 
adding the following line to the workstation's NET.CFG file: 


netware requester 
packet burst off 


See the “packet burst off’ on page 230 for information on Packet Burst. 


Improving Speed by Using Large Internet Packets 


Large Internet Packet (LIP) functionality allows the internet packet size to be 
increased from the default 576 bytes. By allowing the NetWare packet size to 
be increased, LIP enhances transmission over bridges and routers. 


In NetWare v4.0, the workstation requests an acceptable packet size. 
However, unlike previous versions of NetWare, the NetWare server doesn't 
default to 576 bytes when a router is detected. 


Instead, the workstation attempts to send larger packets to the NetWare server. 
The largest packet size that the NetWare server accepts is the packet size used 
to communicate. 


Disabling Large Internet Packets 


LIP functionality is enabled by default on the workstation. To disable it, enter 
the following lines in the NET.CFG file: 


netware requester 
large internet packets off 
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Improving Security by Using Packet Signature 


NCP Packet Signature is an enhanced security feature that protects servers and 
clients using the NetWare Core Protocol by preventing packet forgery. 


Without the NCP Packet Signature installed, a network client can pose as a 
more privileged client to send a forged NCP request to a NetWare server. By 
forging the proper NCP request packet, an intruder could gain Supervisor 
rights and access to all network resources. 


NCP Packet Signature prevents packet forgery by requiring the server and the 
client to "sign" each NCP packet. The packet signature changes with every 
packet. 


NCP packets with incorrect signatures are discarded without breaking the 
client's connection with the server. However, an alert message about the 
invalid packet is sent to the error log, the affected client, and the server 
console. The alert message contains the login name and the station address of 
the affected client. 


A two-part process between the client and the NetWare server determines the 
NCP Packet Signature: 


+ At login, the server and the client determine a shared, secret key known 
as the session key. 


+ For each request or response packet, the server and the client calculate a 
signature based on the session key, a "fingerprint" algorithm, and the 
previous packet's signature. The unique signature is appended to the NCP 
packet. 


If NCP Packet Signature is installed correctly on the server and all of its 
clients, it is virtually impossible to forge a valid NCP packet. 


NOTE: The Packet Burst loadable module, PBURST.NLM, must be loaded on 
NetWare servers in order for NCP Packet Signature to work. However, using 
Packet Burst to transfer data between servers and clients is optional. 
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Packet Signature Options 


Server Levels 


Client Levels 


Table 6 


Because the packet signature process consumes CPU resources and slows 
performance, both for the client and the NetWare server, NCP Packet 
Signature is optional. 


Several signature options are available, ranging from never signing NCP 
packets to always signing NCP packets. NetWare servers and clients both have 
four settable signature levels. 


The signature options for servers and clients combine to determine the level 
of NCP Packet Signature on the network. 


NOTE: Some combinations of server and client packet signature levels may slow 
performance. However, low CPU-demand systems may not show any performance 
degradation. Network supervisors can choose the packet signature level that 
meets both their performance needs and their security requirements. 


Server packet signature levels are assigned by a new SET parameter. See 
Utilities Reference for more information. 


Packet signature levels at the workstation are assigned by using the following 
NET.CFG option: 


netware requester 
signature level number 


Replace number with 0, 1, 2, or 3. The default is 1. 


NCP Packet Signature levels 








Number Explanation 
0 Client does not sign packets 
1 Client signs packets only if the server requests it (Server 


option is 2 or higher) 


2 Client signs packets if the server is capable of signing (server 
option is 1 or higher) 


3 Client signs packets and requires the server to sign packets 
(or login will fail) 
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Effective Packet Signature 


The packet signature levels for the server and the client interact to create the 
"effective" packet signature. Some combinations of server and client levels do 
not allow logging in. 


Table 7 shows the interactive relationship between the server packet signature 
levels and the client signature levels. 








Table 7 Effective Packet Signature of server and client 

IF Server = 0 Server = 1 Server = 2 Server = 3 

Client = 0 No packet No packet No packet No login 
signature signature signature 

Client = 1 No packet No packet Packet signature Packet signature 
signature signature 

Client = 2 No packet Packet signature Packet signature Packet signature 
signature 

Client = 3 No login Packet signature Packet signature Packet signature 








When to Use NCP Packet Signature 


NCP Packet Signature is not required for every installation. Some network 
supervisors may choose not to use NCP Packet Signature because they can 
tolerate certain security risks. 


You may not need to use NCP Packet Signature if: 
+ Only executable programs reside on the server. 


+ All workstation users on the network are known and trusted by the 
supervisor. 


+ Data on the NetWare server is not sensitive; loss or corruption of this data 
will not impact operations. 


You may want to use NCP Packet Signature if: 
¢ An untrustworthy user uses a workstation on the network. 
+ Someone can easily access the network cabling system. 


¢ There is an unattended, publicly accessible workstation on the network. 
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The default NCP Packet Signature level is 1 for clients and 2 for servers. In 
general, this setting provides the most flexibility while still offering protection 
from forged packets. Below are some examples of using different signature 
levels. 


All Information on the Server Is Sensitive 


If an intruder gains access to any information on the NetWare server, it could 
damage the company. 


The network supervisor sets the server to level 3 and all clients to level 3 for 
maximum protection. 


Sensitive and Nonsensitive Information Reside on the Same Server 


The NetWare server has a directory for executable programs and a separate 
directory for corporate finances. 


The network supervisor sets the server to level 2, and the clients that need 
access to corporate finances to level 3. All other clients remain at the default, 
level 1. 


Users Often Change Locations and Workstations 


The network supervisor is uncertain which employees will be using which 
workstations, and the NetWare server contains some sensitive data. 


The network supervisor sets the server to level 3. Clients remain at the default, 
level 1. 


Workstation Is Publicly Accessible 


An unattended workstation is set up for public access to non-sensitive 
information, but another server on the network contains sensitive information. 


The network supervisor sets the sensitive server to level 3 and the unattended 
client to level 0. 


64 NetWare Workstation for OS/2 v2.01 


Packet Signature Troubleshooting Tips 
This section describes some solutions to problems that may be associated with 
using NCP Packet Signature. 

Clients Are Not Signing Packets 
Make sure each OS/2 workstation has NetWare Requester v2.01 installed. 


Make sure that NCP Packet Signature is not turned off in the NET.CFG file. 


Clients Cannot Log In 
Make sure each workstation has NetWare Requester v2.01 installed. 
The following situations do not allow logging in: 
¢ Server packet signature = 3, client signature = 0 
¢ Server packet signature = 0, client signature = 3 
+ Utilities are old and do not support NCP Packet Signature 
+ The Requester is old and does not support NCP Packet Signature. 


“Error Receiving From the NetWork" Appears 


The client is using an old LOGIN.EXE file that does not include NCP Packet 
Signature. Make sure the new LOGIN.EXE and other new utilities are 
installed in the \OS2 subdirectory on all servers on the network. 


Unsecure Clients Log In to Secure Server 


The clients are using an old LOGIN.EXE file that does not include NCP 
Packet Signature. Make sure the new LOGIN.EXE and other new utilities are 
installed in the \OS2 subdirectory on all servers on the network. Add a 
preferred server statement to the NET.CFG file for all clients that have access 
to secure servers (level 3). 
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Using OS/2 Workstations on a 
Token-Ring Network 


Topic 





“Installing Source Routing on the Server” on page 68 
“Installing Source Routing on the Workstation” on page 68 


“Configuring Source Routing on the Workstation” on page 69 


If your Token-Ring network includes IBM source-routing bridges, computers 
use source routing to communicate across those bridges. 


If you do not use source-routing bridges, skip this chapter. 


This chapter explains how to install and configure source routing on NetWare 
servers and OS/2 workstations. NetWare Workstation for DOS and Windows 
explains how to configure source routing on DOS workstations. 


If your network requires source routing, you must install source-routing 
software on both workstations and servers. Novell's source-routing software 
includes: 


+ ROUTE.NLM (for servers) 
+ ROUTE.SYS (for OS/2 workstations) 


This software routes only IPX packets. 
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Installing Source Routing on the Server 


Procedures 
4 At the server console, load ROUTE.NLM by typing 
LOAD ROUTE 


ROUTE.NLM is located in the SYS:SYSTEM directory. You can load it 
with command line parameters. Utilities Reference explains more about 
the parameters. 


You can also load ROUTE.NLM in a startup file. 


2 (Conditional) Load ROUTE.NLM again if you have two network boards 
in your server. 


Use the "board" parameter to specify a board number. For example, type 
LOAD ROUTE BOARD=02 


You can change a source-routing parameter after ROUTE 1s loaded. Type 
the LOAD ROUTE command followed by the parameter you want to 
change. 


Installing Source Routing on the Workstation 


Prerequisites 


Q) Install the Netware Requester with a TOKEN ODI driver. Chapter 3, 
"Installing a NetWare Worsktation," in Workstation Basics and 
Installation explains how to install the Requester. 


Q) Install source routing on all NetWare servers on the same network as 
source-routing bridges by following the instructions in “Installing Source 
Routing on the Server” on page 68. 


QO) Understand source routing. The September 1990 Novell Application 
Notes contains a thorough explanation of source routing. 


Procedures 
4 Open the CONFIG.SYS file in a text editor. 


For example, to use the OS/2 System Editor at an OS/2 command line, 
type: 
E C:\CONFIG.SYS 
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CONFIG.SYS is generally located in the root of your boot drive. 


In the NetWare Requester lines, find the line loading your TOKEN ODI 
driver. 


If you are using Novell-supplied ODI drivers, the driver will be called 
TOKEN.SYS. 


NOTE: If you are using LANSUP.SYS and an NDIS driver, you will not have an ODI 
driver loaded. In this case, find LANSUP.SYS. “Setting Up LANSUP” on page 94 
explains more about LANSUP. 


Following the line that loads the TOKEN ODI driver, type a new line to 
load the ROUTE.SYS driver. 


Specify the correct location of ROUTE.SYS in this line. ROUTE.SYS is 
located where your other Requester files are, usually in C:\NETWARE. 


For example, to load ROUTE.SYS from the default location, type: 


C:\NETWARE\ROUTE.SYS 


4 Save and exit the CONFIG.SYS file. 


5 Use the OS/2 "Shutdown" feature to reboot your machine. 


Configuring Source Routing on the Workstation 


Prerequisites 





Follow the procedures in this section to 
¢ Determine whether you need to configure source routing, and 


+ Configure source routing, if needed. 


Install the NetWare Requester. Chapter 3, "Installing a NetWare 
Workstation," in Workstation Basics and Installation explains how to 
install the Requester. 


Install source routing on the server. See “Installing Source Routing on the 
Server” on page 68. 


Install source routing on the workstation. See “Installing Source Routing 
on the Workstation” on page 68. 


Understand source routing thoroughly. This section does not explain 
source-routing terminology or how packets are routed. You can read IBM 
publications (such as [BM Token-Ring Network Architecture Reference) 
or the September 1990 Novell Application Notes. 
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Procedures 
41 Start the NetWare Requester Installation program. 


You can choose the "Installation" icon from the "Novell" group on your 
desktop. 


2 Choose "This workstation .. ." from the "Configuration" menu. 
3 Verify the location of the NET.CFG file and choose "Edit." 


The "Edit NET.CFG" window appears. See Figure 13 on page 71. You 
can cut and and paste text from the help window at the bottom of the 
screen to the "Current NET.CFG File Contents" window. Use the 
following keys: 


Table 8 Key definitions for the NET.CFG window 


To do this... Use these keys.... 





Highlight text Click and drag with the mouse, or move the 
cursor with the arrow keys while holding down 
the <Shift> key 





Copy text <Ctrl><Insert> 





Cut text (text will reappear <Shift><Delete> 
the next time you refresh the 








window) 
Paste text <Shift><Insert> 
Delete text (deleted text <Ctrl><Delete> 


cannot be pasted) 
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Figure 13 Editing NET.CFG for source routing 




















aa Type NET.CFG 
options and 
settings here. 


Save your 
configuration or 
change your mind. 


Select a 
NET.CFG option, 
setting, or topic. 









| Edit 


he NET.CFG file for this workstation 


NET.CFG Options Current NET.CFG File Contents 
retry count 
retry delay 
sessions 
verify timeout 
NetWare for 05/2 
performance tuning 
remove server memory 
server memory 
Token-Ring source routing 
[i = Me | 
gbr 
mbr 
nodes 
board 











DEF 






Type DEF to broadcast on all routes. Omit DEF to broadcast on a 
single route only. Default = single route broadcast (DEF is omitted). 













Change the default when you are unsure of the stability of one or 
more routes in the network. Using DEF will substantially increases 
network traffic, especially on large, redundant ring networks. 

















ES Select the type 
of information you 
want to see. 


PA Read online 
help for the topic 
you selected. 


4 Select "Token-Ring source routing" from the "NET.CFG Options" box on 
the left of your screen. 


5 Determine whether to change the configuration for the "def", "gbr", 


n. "n 


mbr", "nodes," and "board" settings under "Token-Ring source routing." 
5a Select one of the five settings. 


Example: select "def" 
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5b Read the help window at the bottom of the screen to determine 
whether to change the configuration for the setting. 


You can choose the "Usage," "Description" and "Example" buttons 
on the right of the window to see more information about the setting 
you've selected. 


5c (Optional) If you decide to change the configuration, type the 
configuration lines (as shown in the "Usage" help window) in the 
"Current NET.CFG File Contents" box. 


IMPORTANT: You must follow the format requirements explained in the 
"Format of NET.CFG Options" topic. To see these requirements, select this 
topic from the "NET.CFG Options" box and choose the "Usage" button. 


Repeat steps 5a through 5c for each setting. 
6 Choose "Save." 


7 Exit the NetWare Requester Installation program and use the OS/2 
"Shutdown" feature to reboot your computer. 
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Sharing a Network Board with IBM 
Software 


Use this chapter if you want the NetWare Requester to share a network board 
with one or more of the following IBM software products: 


+ Extended Services 
+ LAN Server 
+ LAN Requester 





Topic 





“How Board Sharing Is Possible” on page 73 
“Setting Up ODINSUP” on page 74 


“Setting Up LANSUP” on page 94 


NOTE: If you have Extended Services or LAN Services, you may also want to set 
up the NetBIOS protocol. After doing the steps in this chapter, you can see “Setting 
Up NetBIOS for OS/2” on page 125. 


How Board Sharing Is Possible 


The NetWare Requester uses protocol drivers and network drivers written to 
the ODI (Open Data-Link Interface) specification. 


Extended Services and LAN Services use protocol drivers and network 
drivers written to the NDIS specification. 


Even though NetWare Requester uses a different driver specification than 
Extended Services and LAN Services, the NetWare Requester can still share 
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a network board with these products. This is possible because of two drivers 
that Novell provides: 


+ ODINSUP.SYS 


The ODINSUP driver lets Extended Services and LAN Services use ODI 
network drivers. Use ODINSUP when you want the ODI network driver 
to control the board. See “Setting Up ODINSUP” on page 74. 


LANSUP.SYS 


The LANSUP driver lets the NetWare Requester use NDIS network 
drivers. Use LANSUP when you want the NDIS driver to control the 
board. See “Setting Up LANSUP” on page 94. 


+ 


Setting Up ODINSUP 


NOTE: Except where noted, the instructions in this section apply whether you have 
Extended Services, LAN Services, or both. However, the sample configuration files 
shown differ depending on what IBM software you have. Be sure to refer to the 
correct files for your environment. 


ODINSUP installation involves three parts, all done in a text editor. Each part 
sets up a different configuration file. You must do all three parts. 





Part 





“Part A: Binding ODI Drivers in PROTOCOL.INI” on page 75 
“Part B: Loading ODINSUP in CONFIG.SYS’ on page 78 
“Part C: Configuring ODINSUP in NET.CFG” on page 80 


“Sample Configuration Files for ODINSUP” on page 85 


ODINSUP supports Ethernet and Token-Ring compatible ODI drivers. It does 
not support ARCnet or PC Network II drivers. 
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Part A: Binding ODI Drivers in PROTOCOL.INI 


In this section, you edit the PROTOCOL.INI file in a text editor to do the 
following: 


Prerequisites 


Procedures 


+ 


+ 


Bind the NDIS protocol stack to the ODI drivers 


Remove the line binding the NDIS protocol stack to the NDIS MAC 
drivers 


NOTE: These instructions are for LAN Server and LAN Requester v2.x. 


Install Extended Services on the workstation. If you have an NDIS driver 
for the network board in your computer, verify that you can get a 
Communications Manager or Database Manager connection. See the 
documentation for Extended Services. 


Install LAN Server or LAN Requester on the workstation. If you have an 
NDIS driver for the network board in your computer, verify that you can 
get connections properly on your LAN Server network. See the 
documentation for LAN Services. 


After installing all IBM software, install the NetWare Requester v2.01 as 
instructed in Chapter 3, "Installing a NetWare Workstation," in 
Workstation Basics and Installation. Using the ODI driver for the board, 
verify that you can get connections properly on your NetWare network. 
Chapter 5, "Workstation Login" in Workstation Basics and Installation 
explains about logging in to a NetWare network. 


NOTE: Once you install the NetWare Requester, Extended Services and LAN 
Services will not be able to use the network board to make connections until you 
have completely set up ODINSUP as instructed in this chapter. 


Open the PROTOCOL.INI file in a text editor. 
For example, to use the OS/2 System Editor at the command line, type: 
E C:\IBMCOM\PROTOCOL. INI 


PROTOCOL.INI is located in the \IBMCOM directory on your boot 
drive. 


Find all occurrences of the lines that bind the NDIS MAC drivers. 
You can search for "Bindings = NDIS MAC driver." 
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If you don't know the name of the NDIS driver to look for, see your 
Extended Services or LAN Services documentation. 


For example, to search for a Token-Ring NDIS driver, find the following 
line: 
Bindings = IBMTOK_NIF 


Bindings lines may be in any of the following sections, depending on 
whether you have Extended Services or LAN Services installed: 


[NETBEUI_nif] 
[LANDD_nif] 


3 Use a semicolon to remark out all Bindings lines found in Step 2. 


For example, your PROTOCOL.INI for a Token-Ring driver might look 
as follows: 


[LANDD_nif] 


Bindings = IBMTOK_NIF 
4 After each remarked-out Bindings line, add a line to bind the NDIS 
protocol to an ODI driver. 


Follow the same syntax as the line you remarked out, using the ODI 
driver name instead of the NDIS driver name. 


For example, to add a line for the TOKEN.SYS ODI driver: 


[LANDD_nif] 


; Bindings = IBMTOK NIF 

Bindings = TOKEN 
Since driver names in the PROTOCOL.INI file cannot start with a 
number, place an X before 3Com drivers and other drivers that start with 
a number (Example: Bindings = X3C503). 
HINT: If you do not know which ODI driver name to use, you can reboot your 
machine. An error message will appear, displaying the name of the ODI driver that 


should be used. If you do this, be sure to reopen the PROTOCOL.INI file and return 
to this step of the procedure. 


5 (Conditional) Type an instance number to bind the NDIS protocol to a 
particular occurrence of a board. 
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If you have two or more network boards using the same ODI driver, the 
NDIS protocol uses the first network board of that type. 


To have NDIS use a board other than the first one found, you can specify 
an instance number. Type the instance number at the end of the driver 
name, with no space between the driver name and the instance number. 


For example, if you have two Token-Ring network boards, have NDIS 
use the second board by typing an instance number for the second board, 
as shown: 


[LANDD_nif] 


; Bindings = IBMTOK NIF 
Bindings = TOKEN2 


6 (Conditional) Bind the NDIS protocol to additional ODI drivers. 


To bind the NDIS protocol to more than one ODI driver, type both driver 
names on the same line, separated by a comma. 


For example, to bind to both an NE2000 driver and an NE1000 driver, 
type: 
Bindings=ne2000,ne1000 
7 Add an empty header for the ODI drivers. 
7a Locate the MAC SECTION of the PROTOCOL.INI file. 
You can search for MAC SECTION. 


7b At the end of the MAC section, type a header for each ODI driver you 
specified in a Bindings line in Steps 4 through 6. 


Use the ODI driver name. For example, for a Token ODI driver, type 
the following line: 


[TOKEN] 


Put a blank line before and after the header section. If the driver name 
starts with a number, you do not need an_X in front of the number for 
this step. 


This ODI driver header is a place holder so that if you configure with 
the LAPS program in the future, the Bindings information will not be 
erased. 


8 Save and exit the PROTOCOL.INI file. 


Do not exit the text editor. Go to “Part B: Loading ODINSUP in 
CONFIG.SYS” on page 78. 
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Part B: Loading ODINSUP in CONFIG.SYS 


In this section, you edit the CONFIG.SYS file in a text editor to do the 
following: 


+ Load the ODINSUP driver 
+ Prevent the NDIS network driver (MAC) from loading 


Prerequisite 


Q) Follow the instructions in “Part A: Binding ODI Drivers in 
PROTOCOL.INI’ on page 75. 


Procedures 
4 Open the CONFIG.SYS file in a text editor. 
CONFIG.SYS is located in the root of your boot drive. 
2 Find the lines that load the NDIS MAC drivers. 
For example, for a token driver, search for the following line: 
DEVICE=C: \IBMCOM\MACS\IBMTOK.0S2 


If you don't know the name of your NDIS driver, see your Extended 
Services or LAN Services documentation. 


3 Remark out the NDIS MAC driver that is equivalent to the ODI driver 
you are using. 


For example, to remark out a Token-Ring NDIS MAC driver, place a REM 
command in front of the line that loads it, as shown: 


REM DEVICE=C: \IBMCOM\MACS\IBMTOK.OS2 


If you have network boards and NDIS drivers for other communications 
software, do not remark out the lines to load those drivers. 


4 In the NetWare Requester lines, find the line loading the ODI driver. 


5 On anew line underneath the ODI driver, insert a line to load the 
ODINSUP protocol. 


ODINSUP is located in the directory where you installed the NetWare 
Requester files (NETWARE by default). 


For example, to load the ODINSUP protocol from the default location, 
type: 
DEVICE=C: \NETWARE\ODINSUP.SYS 
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Table 9 


These components... 


NOTE: If you have the Source-Routing driver, ROUTE.SYS, loaded after the ODI 
driver, put the ODINSUP line after the ROUTE.SYS line. 


6 Verify that your file meets the load order requirements shown in the table 


below. 
By default, these load order requirements will be met. 


If you have rearranged your CONFIG.SYS, it may violate the load order 
requirements. 


Load order requirements for ODINSUP CONFIG.SYS file 





Must load BEFORE these components .. . 





PROTMAN.OS2 (in OS/2 section right after The ODINSUP protocol 


path statements) 





LSL.SYS (in NetWare Requester section) The ODI driver 


The ODINSUP protocol 





The ODI driver (in NetWare Requester The ODINSUP protocol 


section) 





NWIFS.IFS (in NetWare Requester section) NETWKSTA.200 (only in LAN Services configurations) 





6a If your file meets load order requirements, go to Step 8. 
6b If your file violates load order requirements, go to Step 7. 


Rearrange your CONFIG.SYS file to meet load order requirements for 
ODINSUP. 


We suggest you make your file match the sample file shown for your 
environment. See “Sample Configuration Files for ODINSUP” on page 
85 for a list of sample configuration files. 


After rearranging your CONFIG.SYS file, go on to Step 8. 
Save and exit the CONFIG.SYS file. 


Do not exit the text editor. Go to “Part C: Configuring ODINSUP in 
NET.CFG” on page 80. 
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Part C: Configuring ODINSUP in NET.CFG 


Prerequisites 


Procedures 


IMPORTANT: A NET.CFG file is required to use ODINSUP. 
In this section, you edit or create a NET.CFG that does the following: 
+ Enables frame types for ODINSUP. 
+ Specifies to ODINSUP the node address known by Extended Services 


and the format in which that address is transmitted. 
Binds ODINSUP to an ODI driver or drivers. 


Increases the size of the packet that can be transmitted through the Link 
Support layer (if necessary.) 


Follow the instructions in “Part A: Binding ODI Drivers in 
PROTOCOL.INI’ on page 75. 


Follow the instructions in “Part B: Loading ODINSUP in CONFIG.SYS” 
on page 78. 


Open the NET.CFG text file in the text editor. 


NET.CFG is located in the root of your boot drive. If the NET.CFG file 
does not exist, create a new file by that name. 


Enable frame types for ODINSUP. 
2a Type the following line at the top of the file: 
link driver drivername 


Replace drivername with the name of your ODI driver. For example, 
for a Token-Ring driver, type: 


link driver token 
2b Under the Link Driver line, type the lines to enable frame types. 
Enable all frame types supported by the board. 


Use the frame setting to do this. The setting “frame” on page 207 
explains more about frame types and the frame setting. 
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For example, to enable all frame types for Token-Ring, type the 


following: 


link driver token 
frame token-ring 
frame token-ring_ snap 


To enable all frame types for Ethernet, type the following: 


link driver ne2000 
frame ethernet_802.3 
frame ethernet_802.2 
frame ethernet _ii 
frame ethernet_snap 


The first frame defined is the only one used for the initial Get Nearest 
Server request. Therefore, if you have some servers that are using 
only one frame type, such as Ethernet_ 802.3, put that frame type 
first. That way your workstation will be able to make a default 
connection to those servers. 


IMPORTANT: Whenever you edit the NET.CFG file, you must indent 
settings, as well as follow the other format requirements explained in 
“NET.CFG Format Requirements” on page 42. 


3 Read the following chart to determine whether you need to specify a node 
address in the NET.CFG file. 





If you are using... 


Do this... 





Extended Services or 
LAN Services set up for 
universally- 
administered addresses 


You do not need to specify a node address. Go 
to Step 5. 





Extended Services or 
LAN Services set up for 
locally administered 
addresses 


You must specify a node address. Use the 
address shown in the "NetAddress" parameter in 
the PROTOCOL.INI file. Remove the T first. For 
example, if the PROTOCOL.INI file shows the 
line 


NetAddress = "T400000007030" 
the address you specify in NET.CFG is 
400000007030 


Go to Step 4. 
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4 Type a line specifying the node address. 


Type this line under the "Link Driver" option, above or below the lines 
enabling frame types. The node address must be a 6-byte hexadecimal 
number (12 characters). Use the address you located in Step 3. 


For example, to set a node address for a Token-Ring board in an Extended 
Services environment, type: 


node address 400000007030 


If your board supports octet bit reversal, you can specify the address in 
either canonical (least significant bit first) or non-canonical (most 
significant bit first) format. 


By default, the following frames are non-canonical (MSB): 
¢ Token-Ring 

+ PC Network II 

Ethernet frames are canonical (LSB). 


If you specify the address in the format that is not default, you must type 
an M (most significant bit first) or L (least significant bit first) at the end 
of the address to tell ODINSUP which format you used. 


For example, for a Token-Ring environment using the default format for 
the node address, the "Current NET.CFG file contents" box should 
contain lines similar to the following: 


link driver token 
frame token-ring 
frame token-ring_ snap 
node address 400000007030 


Note that an M after the node address is not needed because the address 
is specified most significant bit first, the default format for Token-Ring. 


For a Token-Ring environment using the non-default format for the same 
node address, the "Current NET.CFG file contents" box should contain 
lines similar to the following: 


link driver token 
frame token-ring 
frame token-ring_snap 
node address 020000000E0CL 


In this case, an L after the node address is needed because the address is 
specified in least significant bit first format, the format which is not the 
default for Token-Ring. 
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For an Ethernet Extended Services environment, the NET.CFG file 
should now contain lines similar to the following: 


link driver ne2000 
frame ethernet 802.3 
frame ethernet_802.2 
frame ethernet _ii 
frame ethernet_snap 
node address 00001B1B055C 


NOTE: If you do not know the node address, you can type a "dummy" address and 
go to the next step. When you reboot your machine, an error message showing the 
correct address will be displayed. At that point, you can edit the NET.CFG file again 
and insert the address that was displayed at boot time. 


Bind ODINSUP to one or more ODI drivers. 


When ODINSUP is bound to a driver, the network board for that driver is 
used for Extended Services and LAN Services transmissions. 


5a Type the following lines: 


protocol odinsup 
bind drivername 


Replace drivername with the name of the ODI driver you installed 
with the Requester. 


For example, for a Token-Ring ODI driver, type 


protocol odinsup 
bind token 


5b (Conditional) Specify an instance number if you have two or more 
boards using the same ODI driver. 


If you have two or more network boards using the same ODI driver, 
ODINSUP searches the network board slots in order and binds only 
to the first board of that type it finds. 


To have ODINSUP bind to a board other than the first one found, you 
can specify an instance number. 


ODINSUP can be bound to a maximum of four boards. 


For example, if you have two Token-Ring network boards, bind 
ODINSUP to both boards by typing an instance number for the 
second board, as shown: 


protocol odinsup 
bind token 
bind token 2 
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“Protocol ODINSUP” on page 234 explains more about the 
"Protocol Odinsup" option. 


6 (Optional) Increase the size of the packet transmitted through the Link 
Support Layer. 


Increasing the packet size may improve transmission speed if you are 
using a Token-Ring 16/4 board. 


For other kinds of board, see the board documentation to determine the 
maximum packet size supported by the board. If the board supports a 
packet size larger than 1,514 (the Link Support default), transmission 
speed may improve if you increase the Link Support Layer default to the 
board's maximum allowed size. 


To increase the default: 

6a Under the Link driver lines, type the following line: 
link support 

6b Under the Link Support line, type the following line: 
buffers number size 


Indent the line. Replace number with a number of buffers greater 
than 1. Replace buffer_size with a number of bytes greater than 576. 


The Requester cannot use more than 64 KB of memory for 
communication buffers. Header information takes 5 KB. This means 
that the buffer number multiplied by the buffer size (plus the header 
information) cannot be greater than 65,536 bytes. For example, 20 
buffers multiplied by 1,514 bytes equals 30,280 bytes. 


“Link Support” on page 216 explains more information about using 
this option. 


For example, you might type 


link support 
buffers 14 4202 


IMPORTANT: For Token-Ring 16/4 boards, the NetWare Requester will 
probably have maximum performance if you specify 14 buffers, each with a 
size of 4,202 bytes, as shown in the example above. 


7 Save your changes and exit the NET.CFG file. 
8 Exit the text editor. 


9 Choose "Shutdown" from the OS/2 System menu to reboot your machine. 
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When your machine starts again, ODINSUP support will be completely 
set up. NetWare Requester and Extended Services/LAN Services will 
then use the same ODI driver and board to transmit on the network. 


Sample Configuration Files for ODINSUP 


This section contains sample CONFIG.SYS, NET.CFG, and PROTOCOL.INI 
files for both Extended Services and LAN Requester environments. 


NOTE: If you follow the steps in “Setting Up ODINSUP” on page 74, your 
configuration files will look like the ones shown. We recommend following the steps 
rather than just referring to these sample files. 


Sample Files 





“LANSUP Files from an Extended Services Environment” on page 103 
“Extended Services Token-Ring PROTOCOL.INI file for ODINSUP” on page 86 
“Extended Services Token-Ring CONFIG.SYS file for ODINSUP (part 1)” on page 87 
“Extended Services Token-Ring CONFIG.SYS file for ODINSUP (part 2)” on page 88 


“Extended Services Token-Ring NET.CFG file for ODINSUP” on page 89 





“LANSUP Files from a LAN Requester Environment” on page 107 
“LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP (part 1)” on page 90 
“LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP (part 2)” on page 91 
“LAN Requester Token-Ring CONFIG.SYS file for ODINSUP (part 1)” on page 92 
“LAN Requester Token-Ring CONFIG.SYS file for ODINSUP (part 2)” on page 93 


“LAN Requester Token-Ring NET.CFG file for ODINSUP’” on page 94 
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ODINSUP Files from an Extended Services Environment 


These files came from a computer with the following software installed: 
+ OS/2 v2.0 
+ Extended Services v1.0 (locally-administered addresses) 


+ NetWare Requester v2.01 with ODINSUP. 


The computer used Communications Manager to make a LAN connection to 
an IBM host. 


Figure 14 illustrates a PROTOCOL.INI file for this environment. 


Figure 14 Extended Services Token-Ring PROTOCOL.INI file for ODINSUP 


[PROT_MAN] 
DRIVERNAME = PROTMAN$ 


[IBMLXCFG] 
LANDD_nif = LANDD.NIF 
IBMTOK_nif = IBMTOK.NIF 


Remark out this line binding 


[LANDD_ nif] the NDIS TOKEN driver. 
DRIVERNAME = LANDD$ 
; BINDINGS = IBMTOK_nif 
BINDINGS = TOKEN = 
Links = 41 
Users = 4 
Max_Saps = 4 
NetAddress = Oe ee, 





Add this line binding the 
ODI TOKEN driver. 





This node address must be 
(IBMTOK_nif] specified in the NET.CFG. 


DRIVERNAME = IBMTOK$ 





Include this line at the end 


[TOKEN] + of the file. Put a blank line 





before and after it. 
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Figure 15 and Figure 16 illustrate a CONFIG.SYS file for the example 
Extended Services environment. 


Figure 15 Extended Services Token-Ring CONFIG.SYS file for ODINSUP (part 1) 


LIBPATH=.;D:\OS2\DLL;D:\MUGLIB\DLL;D:\OS2\MDOS;D:\CMLIB\DLL;D\; 
D:\OS2\APPS\DLL;D:\IBMCOM\DLL;D:\NETWARE; 

SET 
PATH=D:\0S2;D:\MUGLIB;D:\OS2\SYSTEM;D:\OS2\MDOS\WINOS2;D:\ 
CMLIB;D:\CMLIB\APPN;D:\OS2\INSTALL;D:\;3D:\OS2\MDOS;D:\OS2\APPS; 
L:\OS2;P:\0S2;D:\NETWARE; 

SET 

DPATH=D:\0S2;D:\MUGLIB\DLL;D:\CMLIB;D:\CMLIB\APPN;D:\0S2\ 
SYSTEM;D:\OS2\MDOS\WINOS2;D:\0SA\INSTALL;D:\;D\OS2\BITMAP;D:\ 
OS2\MDOS;D:\0S2\APPS;D:\IBMCOM;L\0S2;D:\NETWARE; 


DEVICE=D:\ibmcom\lanmsgdd.os2 /I:D:\ibmcom Protocol Manager 
DEVICE=D:\ibmcom\protman.os2 /|:D:\ibmcom is loaded by — 
DEVICE=D:\ibmcom\protocol\LANDD.OS2 Extended Services. 


DEVICE=D:\ibmcom\protocol\_LANDLLDD.OS2 


DEVICE=D:\CMLIB\ACSLDLAN.SYS 
RUN=D:\0S2\EPW.EXE 
RUN=D:\ibmcom\protocol\landll.exe 
RUN=D:\ibmcom\protocol\netbind.exe 





RUN=D:\iobmcom\lanmsgex.exe rem You must remark 
DEVICE=D:\IBMCOM\MACS\IBMT OK.OS2- out the NDIS 
DEVICE=D:\CMLIB\APPN\CMKFMDE.SYS TOKEN driver. 


Continued on next page. 
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Figure 16 Extended Services Token-Ring CONFIG.SYS file for ODINSUP (part 2) 





REM --- NetWare Requester statements BEGIN --- 
SET NWLANGUAGE=ENGLISH 









NetWare 


Requester 

DEVICE=D:\NETWARE\LSL.SYS statements 

RUN=D:\NETWARE\DDAEMON.EXE are loaded 
DEVICE=D:\NETWARE\TOKEN.SYS by the 

equester 


DEVICE=D:NETWARE\ROUTE.SYS 
DEVICE=D:\NETWARE\ODINSUP.SYS 
DEVICE=D:\NETWARE\IPX.SYS 
DEVICE=D:\NETWARE\SPX.SYS 
RUN=D:\NETWARE\SPDAEMON.EXE 
DEVICE=D:\NETWARE\NMPIPE.SYS l 
rem DEVICE=D:\NETWARE\NPSERVER.SYS y 
RUN=D:\NETWARE\NPDAEMON.EXE 
DEVIGE=D:\NETWARE\NWREQ.SYS 
IFS=D:\NETWARE\NWIEFS.IFS 
RUN=D:\NETWARE\NWDAEMON.EXE 

rem DEVICE=D:\NETWARE\NETBIOS.SYS 

rem RUN=D:\NETWARE\NBDAEMON.EXE 
DEVICE=D:\NETWARE\VIPX.SYS 
DEVICE=D:\NETWARE\VSHELL.SYS PRIVATE 

REM --- NetWare Requester statements END --- 


installation. 






You must include 
this line to load 
ODINSUP. 






Load order requirements 


1. PROTMAN.OS2 
2. LSL.SYS 

3. ODI driver 

4. ODINSUP 
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Figure 17 illustrates a NET.CFG file for the example Extended Services 
environment. 


Figure 17 Extended Services Token-Ring NET.CFG file for ODINSUP 


link driver|token ODI driver name. 


node address 400000007030 Bind both available 
frame token-ring TOKEN frame types 
frame token-ring_snap — to the ODI driver. 


Protocol odinsup Bind ODINSUP 
bindįtoken] ————— to the ODI driver. 





















































Put a blank line at 
the end of the file 
and between options. 





Order requirements 


1. Link driver 
2. Protocol ODINSUP 





ODINSUP Files from a LAN Requester Environment 
These files came from a computer with the following software installed: 
+ OS/2 v2.0 
+ LAN Requester v2.0 
+ NetWare Requester v2.01 with ODINSUP 
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Figure 18 and Figure 19 illustrate a Protocol.INI for the example LAN 
Requester environment. 


Figure 18 LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP (part 1) 


[PROT_MAN] 
DriverName = PROTMAN$ 
[IBMLXCFG] 
IBMTOK_nif = IBMTOK.nif 
NETBEUL nif = NETBEUL. nif 
LANDD_ nif = LANDD.nif 


[NETBEUL nif] 


Drivel Nene = Ne Oeil Comment out this line binding 
» Bindings = eon at the NDIS TOKEN driver. 
Bindings = TOKEN 


ETHERAND_TYPE = "I" 








USEADDRREV = "YES" Add this line binding the 
SESSIONS = 40 ODI TOKEN driver. 
NCBS = 95 

NAMES = 21 


SELECTORS = 5 
USEMAXDATAGRAM = "NO" 
ADAPTRATE = 1000 
WINDOWERRORS = 0 

TI = 30000 

T1 = 500 

T2 = 200 

MAXIN = 1 

MAXOUT = 1 
NETBIOSTIMEOUT = 500 
NETBIOSRETRIES = 8 
NAMECACHE = 0 
PIGGYBACKACKS = 1 
DATAGRAMPACKETS = 2 
PACKETS = 350 
PIPELINE = 5 
MAXTRANSMITS = 6 


MINTRANSMITS = 2 Continued on next page. 
DLCRETRIES = 5 
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Figure 19 LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP (part 2) 


[LANDD_ nif] 


. Sees eMIeK an Comment out this line binding 
Bindings = TOKEN = the NDIS TOKEN driver. 


ETHERAND_TYPE = "I" 
SYSTEM_KEY = 0x0 
OPEN_OPTIONS = 0x2000 
TRACE = 0x0 

LINKS = 8 

MAX_SAPS = 3 
MAX_G_SAPS = 0 

USERS = 3 

TI_TICK_G1 = 255 
T1_TICK_G1 = 15 
T2_TICK_G1 =3 
TI_TICK_G2 = 255 
T1_TICK_G2 = 25 
T2_TICK_G2 = 10 
IPACKETS = 250 
UIPACKETS = 100 
MAXTRANSMITS = 6 
MINTRANSMITS = 2 
TCBS = 64 GDTS = 30 
ELEMENTS = 800 









Add this line binding the 
ODI TOKEN driver. 






;*--------------- MAC SECTION ----------------- A 
[IBMTOK_nif] 

DriverName = IBMTOK$ 

PRIMARY 

MAXTRANSMITS = 12 

RECVBUFS = 2 

RECVBUFSIZE = 256 

XMITBUFS = 1 


You must include this line. 
[TOKEN] Put a blank line before and after it. 
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Figure 20 and Figure 21 illustrate a CONFIG.SYS file for the example LAN 
Requester environment. 


Figure 20 LAN Requester Token-Ring CONFIG.SYS file for ODINSUP (part 1) 


LIBPATH=C:\MUGLIB\DLL;C:\IBMLAN\N ETLIB;.;C:\OS2\DLL;C:\OS2\MDOS;C:\;C\0S2\ 
soe A\NETWARE;C;\ibmcom\dll; 
ET 


PATH=C:\IBMLAN\NETPROG;CAMUGLIB;C:\OS2;C\OS2\SYSTEM;C:\OS2\MDOS \ 

aa a a C:\NETWARE; 
E 

DPATH=C:\IBMLAN\NETPROG;C:AIBMLAN;C:\MUGLIB;C:\0S2;CA\OS2\SYSTEM; C:\0S2\ 

MDOS\WINOS2;C:\OSA\INSTALL;C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C\\OS2\APPS;LAOS2 

C:NETWARE:C:\ibmcom; 


DEVICE=C:\ibmcom\lanmsgdd.os2 /I:C:\ibmcom Protocol Manager 
DEVICE=C:\ibmcom\protman.os2 /I:C:\iomcom + is loaded by 
DEVICE=C:\ibmcom\protocol\LANDD.OS2 LAN Services. 
DEVICE=C:\ibmcom\protocol\_LANDLLDD.OS2 


CODEPAGE=437,850 The LAN Services 
DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP NETBIOS driver loads. 
DEVICE=C:\IBMCOM\PROTOCOL\NETBEUI.OS2 

REM DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2 
DEVICE=C:\IBMLAN\NETPROG\RDRHELP.200 You must remark 


out the NDIS 


Continued on next page. TOKEN driver. 
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Figure 21 LAN Requester Token-Ring CONFIG.SYS file for ODINSUP (part 2) 





REM --- NetWare Requester statements BEGIN --- + W 

SET NWLANGUAGE=ENGLISH NetWare 
DEVICE-C:\NETWARE\LSL.SYS-—{LSL loads. ] Requester 
RUN=C:\NETWARE\DDAEMON.EXE statements 
DEVICE=C:\NETWARE\TOKEN.SYS are loaded 
DEVICE=C:\NETWARE\ROUTE.SYS 








DEVICE=C:\NETWARE\ODINSUP.SYS + the 
DEVICE=C:\NETWARE\IPX.SYS You must include , equester 
DEVICE=C:\NETWARE\SPX.SYS his li load installation. 
RUN=C:\NETWARE\SPDAEMON.EXE this line to loa 

rem DEVICE=C:\NETWARE\NMPIPE.SYS ODINSUP. 





rem DEVICE=C:\NETWARE\NPSERVER.SYS 
rem RUN=C:\ANETWARE\NPDAEMON.EXE 


DEVICE=C:\NETWARE\NWREQ.SYS NetWare file 
IFS=C:\NETWARE\NWIFS.IFS system loads. l 





RUN=C \NETWARE\NWDAEMON.EXE 
rem DEVICE=C:\NETWARE\NETBIOS.SYS vy 
rem RUN=C:\NETWARE\NBDAEMON.EXE 
DEVICE=C:\NETWARE\IPX.SYS 

DEVICE=C:\NETWARE\VSHELL.SYS PRIVATE 

REM --- NetWare Requester statements END --- 


; The LAN Services 
IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN /N file system loads 
DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2 i 
RUN=C:\IBMLAN\NETPROG\LSDAEMON.EXE 
RUN=C:\ibmcom\protocol\landll.exe 


RUN=C:\ibmcom\protocol\netbind.exe 
RUN=C:\ibmcom\lanmsgex.exe 


Load order requirements 


1. PROTMAN.OS2 
2. LSL.SYS 

3. ODI driver 

4. ODINSUP 


1. NWIFS.IFS 
2. NETWKSTA.200 
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Figure 22 illustrates a NET.CFG file for the example LAN Requester 
environment. 


Figure 22 LAN Requester Token-Ring NET.CFG file for ODINSUP 














link driver|token 
frame token-ring 
frame token-ring_snap — 








ODI driver name. 








Bind both available 
TOKEN frame types 
to the ODI driver. 


Bind the ODI driver 
to ODINSUP. 














protocol odinsup 
bind|token 





























Put a blank line at 
the end of the file 
and between options. 


Order requirements 


1. Link driver 
2. Protocol ODINSUP 


Setting Up LANSUP 


NOTE: Except where noted, the instructions in this section apply whether you have 
Extended Services, LAN Services, or both. However, the sample configuration files 
shown differ depending on what IBM software you have. Be sure to refer to the 
correct files for your environment. 


Setting up LANSUP involves three parts. The first two parts are required; the third 
is optional. The parts and their page numbers are shown in the following table: 


Part 





“Part A: Loading LANSUP in CONFIG.SYS’ on page 95 
“Part B: Configuring LANSUP in NET.CFG” on page 96 
“Part C: Increasing Packet Size for LANSUP (Optional)” on page 101 


“Sample Configuration Files for LANSUP” on page 103 
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Novell's LAN Support (LANSUP) device driver replaces the CMGRLAN and 
TOKENEE modules used in the NetWare Requester v1.3. CMGRLAN and 
TOKENEE are not supported in the NetWare Requester v2.01. 


LANSUP works with NDIS drivers for PC Network II, Ethernet, and Token- 
Ring network boards. 


Part A: Loading LANSUP in CONFIG.SYS 


Prerequisites 


Procedures 


In this section, you use the NetWare Requester installation program to load 
LANSUP in the CONFIG.SYS file. 


If you have not yet installed the NetWare Requester, you can install the 
Requester at the same time as you install LANSUP. 


NOTE: These instructions are for LAN Server and LAN Requester v2.x. 


Q) Install Extended Services on the workstation. Verify that you can get a 
Communications Manager or Database Manager connection. See the 
documentation for Extended Services. 


ü Install LAN Server or LAN Requester on the workstation. Verify that you 
can get a connection on your LAN Server network. See the 
documentation for LAN Services. 


4 Start the NetWare Requester Installation program. 


If the Requester is not installed, you can start the program from your 
WSOS2_1 diskette. Type INSTALL. You can install the Requester with 
this procedure. 


If the Requester is already installed, you can start the program by 
choosing the "Installation" icon from the "Novell" group on your desktop. 


2 Choose "Requester on Workstation" from the "Installation" menu. 
3 Verify the target and source directory and choose "OK." 


4 Select an action from the "Requester Installation" screen based on 
whether the Requester is installed: 


4a Ifthe Requester is not installed, select "Edit CONFIG.SYS and Copy 
All Files . . . " and choose "OK." 
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4b Ifthe Requester is already installed, select "Only Edit CONFIG.SYS 
..." and choose "OK." 


5 Select LANSUP as the ODI driver for your network board and choose 
"Continue. . ." 


Selecting LANSUP inserts the following line in the correct place in your 
COMNFIG.SYS file: 


DEVICE=drive: \NETWARE\LANSUP.SYS 


6 Select your preferences for NetWare support for DOS and Windows 
applications and choose "Continue . . ." 


7 Select your preferences for optional protocol support and choose "Save . 


8 Verify the filename and location and choose "OK." 


If you have not installed the Requester, the "Copy Requester Files" screen 
appears. Continue with Step 9. 


If you have installed the Requester, the main installation menu appears. 
Go to “Part B: Configuring LANSUP in NET.CFG” on page 96. 


9 Choose "Copy" and follow the screens to finish installing the Requester. 


When the main menu returns, go to “Part B: Configuring LANSUP in 
NET.CFG” on page 96. 


Part B: Configuring LANSUP in NET.CFG 
IMPORTANT: A NET.CFG file is required to use LANSUP. 
In this section, you edit or create a NET.CFG file that does the following: 
¢ Enables frame types for LANSUP 


+ Specifies to LANSUP the node address used by the network board and the 
format that address is transmitted in 


In this section, you also decide whether to increase the size of the packet that 
can be transmitted through LANSUP. 


Prerequisite 


Q) Install the NetWare Requester with LANSUP by following the 
instructions in “Part A: Loading LANSUP in CONFIG.SYS” on page 95. 
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Procedures 


Table 10 


1 Choose "This workstation . .." from the "Configuration" menu of the 


NetWare Requester installation program. 


If the NetWare Requester installation program is not running, complete 
the steps in “Part A: Loading LANSUP in CONFIG.SYS” on page 95 and 
then return here. 


Verify the location of the NET.CFG file and choose "Edit." 
The "Edit NET.CFG" window appears. 


You can choose a topic in the "NET.CFG Options" box on this screen to 
get information about a topic. Then read the help window at the bottom 
of the screen. 


Choose the "Usage," "Description" and "Example" buttons on the right of 
your screen to see more information about the topic you've selected. 


For example, to see what frame types are supported for Token-Ring 
drivers, choose "frame" from under "Link Driver" in the "NET.CFG 
Options" box. Then read the information in the help window. 


In the "Current NET.CFG File Contents" box, type the following line: 


link driver lansup 


4 Under the Link Driver line, type lines to enable at least one frame type. 


LANSUP can be used with Ethernet, Token-Ring, and PCNet boards. 
Table 10 lists the supported frame types for LANSUP: 


List of frame types supported by LANSUP 


Board Frame types supported 





Token-Ring TOKEN-RING 


TOKEN-RING_SNAP 





Ethernet ETHERNET_802.2 


ETHERNET_SNAP 





PCNet IBM_PCN2_ 802.2 


IBM_PCN2_SNAP 
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For example, to enable a frame types for Token-Ring, type the following: 


link driver lansup 
frame token-ring 


To enable both frame types for Ethernet, type the following: 


link driver lansup 
frame ethernet_802.2 
frame ethernet_snap 


The first frame defined is the only one used for the initial Get Nearest 
Server request. Therefore, if you have some servers that are using only 
one frame type, such as Ethernet_802.3, put that frame type first. That 
way your workstation will be able to make a default connection to those 
servers. 


IMPORTANT: Use the Space bar to indent the lines. The <Tab> key moves you 
to the next box on the screen. Put a blank line at the end of the file. 


You must follow these and other format requirements explained in the "Format of 
NET.CFG Options" topic. To see these requirements, select this topic from the 
"NET.CFG Options" box and choose the "Usage" button. Then read the 
information in the help window at the bottom of the screen. 


5 Read the following chart to determine what node address you should use. 





If you are using... Get the node address from here... 





Extended Services or Use the address assigned to the board by the 
LAN Services set up for vendor. 
universally- administered 





addresses 

Extended Services or Use the address shown in the "NetAddress" 

LAN Services set up for parameter in the PROTOCOL.INI file. Remove the 
locally administered T first. For example, if the PROTOCOL.INI file 
addresses shows the line 


NetAddress = "T400000007030" 
the address you specify in NET.CFG is 


400000007030 





6 In the "Current NET.CFG File Contents" box, type a line to specify the 
node address. 
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Type this line under the "Link Driver" option, above or below the lines 
enabling frame types. The node address must be a 6-byte hexadecimal 
number (12 characters). 


For example, to set a node address for a Token-Ring board in a LAN 
Services environment, type: 


node address 10005a8c62d4 


If your board supports octet bit reversal, you can specify the address in 
either canonical (least significant bit first) or non-canonical (most 
significant bit first) format. 


By default, the following frames are non-canonical (MSB): 
+ Token-Ring 

+ PC Network II 

Ethernet frames are canonical (LSB). 


If you specify the address in the format that is not default, you must type 
an M (most significant bit first) or L (least significant bit first) at the end 
of the address to tell ODINSUP which format you used. 


For example, for a Token-Ring environment using the default format for 
the node address, the "Current NET.CFG file contents" box should 
contain lines similar to the following: 


link driver lansup 
frame token-ring 
node address 10005a8c62d4 


Note that an M after the node address is not needed because the address 
is specified most significant bit first, the default format for Token-Ring. 


For a Token-Ring environment using the non-default format for the same 
node address, the "Current NET.CFG file contents" box should contain 
lines similar to the following: 


link driver lansup 
frame token-ring 
node address 08005A31462BL 


In this case, an L after the node address is needed because the address is 
specified in least significant bit first format, the format which is not the 
default for Token-Ring. 
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For an Ethernet environment, the "Current NET.CFG file contents" box 
should contain lines similar to the following: 


link driver lansup 
frame ethernet_802.2 
frame ethernet_snap 
node address 00001B1B055C 


NOTE: If you do not know the node address, you can type a "dummy" address and 
go to the next step. When you reboot your machine, an error message showing the 
correct address will be displayed. At that point, you can edit NET.CFG again and 
insert the address that was displayed at boot time. 


7 Decide whether to increase the size of the packet transmitted to the NDIS 
driver by LANSUP. 


Increasing the packet size may improve transmission speed if you are 
using a Token-Ring 16/4 board. 


For other kinds of board, see the board documentation to determine the 
maximum packet size supported by the board. If the board supports a 
packet size larger than xxx, (the Link Support default), transmission 
speed may improve if you increase the Link Support Layer default to the 
board's maximum allowed size. 


7a If you want to increase the packet size, go to “Part C: Increasing 
Packet Size for LANSUP (Optional)” on page 101. 


7b If you do not want to increase the packet size, go to Step 8. 
8 Choose "Save..." 
9 Exit the NetWare Requester Installation program. 
10 Choose "Shutdown" from the OS/2 System menu to reboot your machine. 


When your computer starts again, LANSUP support will be set up. The 
NetWare Requester and Extended Services or LAN Services will then use 
the same NDIS driver and board to transmit on the network. 
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Part C: Increasing Packet Size for LANSUP (Optional) 


Prerequisites 


Procedures 


Only do this section if you were directed to come here in Step 7a on page 100. 


In this section, you 


¢ Edit the NET.CFG file to increase the size of the packet that can be 


transmitted through LANSUP. 


Edit the PROTOCOL.INI to increase the size of the packet that can be 
transmitted through the NDIS drivers. 


Install the NetWare Requester with LANSUP by following the 
instructions in “Part A: Binding ODI Drivers in PROTOCOL.INI” on 
page 75. 


Follow the instructions in “Part B: Configuring LANSUP in NET.CFG” 
on page 96. 


Select "Link support" in the "NET.CFG Options" box on the left of your 
screen. 


If the Requester installation program is not open to the "Edit NET.CFG 
Window", complete the steps in “Part B: Configuring LANSUP in 
NET.CFG” on page 96. Then come back to this step. 


Select "buffers" under "Link Support." 


Read the information in the help window at the bottom of the screen to 
see how to set the Link Support buffers. 


You can choose the "Usage," "Description," and "Example" buttons on 
the right of your screen to see more information about Link Support. 


In the "Current NET.CFG File Contents," type lines to change the "Link 
Support buffers" setting. 


Follow the usage requirements shown in the help window. 


Indent the line. Replace Replace number with a number of buffers greater 
than 1. Replace buffer_size with a number of bytes greater than 576. 


The Requester cannot use more than 64 KB of memory for 
communication buffers. Header information takes 5 KB. This means that 
the buffer number multiplied by the buffer size (plus the header 
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information) cannot be greater than 65,536 bytes. For example, 20 buffers 
multiplied by 1,514 bytes equals 30,280 bytes. 


“Link Support” on page 216 explains more information about using this 
option. 


For example, you might type: 


link support 
buffers 14 4202 


IMPORTANT: For Token-Ring 16/4 boards, the NetWare Requester will probably 
have maximum performance if you specify 14 buffers, each with a size of 4,202 
bytes, as shown in the example above. 


5 Choose "Save..." 

6 Exit the NetWare Requester installation program. 
Without rebooting your machine, go to Step 7. 

7 Run the IBM LAPS program to edit PROTOCOL.INI.. 


8 Change the transmit buffer size to a number 6 bytes larger than the 
number you set for the Link Support buffer size in Step 4. 


The value you specify must be a multiple of 8. See your LAPS 
documentation for more information about changing the transmit buffer 
size. 


IMPORTANT: Use a 4208 transmit buffer size if you are using Token-Ring 16/4 
boards. 


The LAPS program inserts the following line in NDIS MAC driver 
section of your PROTOCOL.INI: 


XMITBUFSIZE = 4208 
9 Exit the LAPS program. 
10 Choose "Shutdown" from the OS/2 System menu to reboot your machine. 
When your machine starts again, LANSUP support will be set up. 


NetWare Requester and Extended Services/LAN Services will transmit to 
the network from the same NDIS driver and network board. 
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Sample Configuration Files for LANSUP 


This section contains sample CONFIG.SYS, NET.CFG, and PROTOCOL.INI 
files for both Extended Services and LAN Requester environments. 


NOTE: If you follow the steps in “Setting Up LANSUP” on page 94, your 
configuration files will look like the ones shown. We recommend following the steps 
rather than just referring to these sample files. 


Sample Files 





“LANSUP Files from an Extended Services Environment” on page 103 
“Extended Services Token-Ring CONFIG.SYS file for LANSUP (part 1)” on page 104 
“Extended Services Token-Ring NET.CFG file for LANSUP” on page 105 


“Extended Services Token-Ring PROTOCOL.INI file for LANSUP (part 1)” on page 106 





“LANSUP Files from a LAN Requester Environment” on page 107 
“LAN Requester Token-Ring CONFIG.SYS file for LANSUP (part 1)” on page 108 
“LAN Requester Token-Ring NET.CFG file for LANSUP” on page 110 


“LAN Requester Token-Ring PROTOCOL. INI file for LANSUP (part 1)” on page 111 


LANSUP Files from an Extended Services Environment 


These files came from a computer with the following software installed: 
+ OS/2 v2.0 


¢ Extended Services v1.0 (locally administered addresses) 


+ NetWare Requester v2.01 with LANSUP. 


The computer used Communications Manager to make a LAN connection to 
an IBM host. Figure 23 and Figure 24 illustrate a CONFIG.SYS file. 
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Figure 23 Extended Services Token-Ring CONFIG.SYS file for LANSUP (part 1) 


LIBPATH=.;C:\OS2\DLL;C:\MUGLIB\DLL;C\OS2\MDOS;CACMLIB\DLL;C:;C \OS2\APPS\ 
DLL;C\NETWARE;C:\ibmcom(\dll; 

SET 

PATH=C:\OS2;C AMUGLIB;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\CMLIB;C \CMLIB\ 
APPN;C:\OS2\INSTALL;C:\;C \OS2\MDOS;C:\OS2\APPS;LA\OS2;P: \OS2;C:\NETWARE; 
SET 

DPATH=C:\0S2;C:\AMUGLIB\DLL;C:\CMLIB;C:\CMLIB\APPN;C\OS2\SYSTEM;C :\OS2\ 
MDOS\WINOS2;C:\OSA\INSTALL;C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C: \OS2\APPS;L:\ 
OS2;C:\NETWARE;C:;\ibmcom; 


DEVICE=C:\ibmcom\lanmsgdd.os2 /I:C:\ibmcom Protocol Manager 
DEVICE=C:\ibmcom\protman.os2 /I:C:\ibmcom » is loaded by 

DEVICE=C:\ibmcom\protocol\LANDD.OS2 Extended Services. 
DEVICE=C:\ibmcom\protocol\_LANDLLDD.OS2 





DEVICE=C:\CMLIB\ACSLDLAN.SYS 
RUN=C:\OS2\EPW.EXE NDIS TOKEN driver 
DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2 + is loaded by 
RUN=C:\ibmcom\protocol\landll.exe Extended Services. 
RUN=C:\ibmcom\protocol\netbind.exe 
RUN=C:\ibmcom\lanmsgex.exe 
DEVICE=C:\CMLIB\APPN\CMKFMDE.SYS 








REM --- NetWare Requester statements BEGIN --- 
SET NWLANGUAGE=ENGLISH 


DEVICE=C:\NETWARE\LSL.SYS LSL loads. Ae boagn 


RUN=C:\NETWARE\DDAEMON.EXE 


DEVICE=C:\NETWARE\LANSUP.SYS LANSUP loads. eae 


DEVICE=C:\NETWARE\ROUTE.SYS Regüester 
DEVICE=C:\NETWARE\IPX.SYS . q . 
installation. 


Continued on next page. i 
y 


NetWare 








e 
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Figure 24 Extended Services Token-Ring CONFIG.SYS file for LANSUP (part 2) 


DEVICE=C:\NETWARE\SPX.SYS 
RUN=C:\NETWARE\SPDAEMON.EXE 
DEVICE=C:\NETWARE\NMPIPE.SYS 

rem DEVICE=C:\NETWARE\NPSERVER.SYS 
RUN=C:\NETWARE\NPDAEMON.EXE 
DEVICE=C:\NETWARE\NWREQ.SYS 
IFS=C:\NETWARE\NWIFS.IFS 
RUN=C:\NETWARE\NWDAEMON.EXE 

rem DEVICE=C:\NETWARE\NETBIOS.SYS 
rem RUN=C:\NETWARE\NBDAEMON.EXE 
DEVICE=C:\NETWARE\IPX.SYS 
DEVICE=C:\NETWARE\VSHELL.SYS PRIVATE 
REM --- NetWare Requester statements END --- 


Figure 25 illustrates a NET.CFG for the example Extended Services 
environment. 


Figure 25 Extended Services Token-Ring NET.CFG file for LANSUP 


link driver lansup I Set node address. 


node address 10005a8c62d4M_ | Bind both available 














frame token-ring TOKEN frame types Locally-administered 
frame token-ring_snap to LANSUP. addresses 

link support Use the address specified 
buffers 14/4202 in "NetAddress" in 





PROTOCOL.INI. 





Universally-administered 
"XMITBUFSIZE" in addresses 


PROTOCOL.INI 


Use the address assigned 
to the board by the vendor. 


must be 6 more than 
this number and 
divisible by 8. 


You can increase Link 
Support buffer size for 4 KB 
boards. 
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Figure 26 and Figure 27 illustrate a PROTOCOL.INI for the example 
Extended Services environment. 


Figure 26 Extended Services Token-Ring PROTOCOL.INI file for LANSUP (part 1) 


[PROT_MAN] 
DriverName = PROTMAN$ 


[IBMLXCFG] 
IBMTOK_nif = IBMTOK.NIF 
LANDD_nif = LANDD.NIF 


[LANDD_ nif] 


DriverName = LANDD$ NDIS TOKEN 
Bindings = IBMTOK_nif « driver is bound 
ETHERAND_TYPE ="I" ` 


SYSTEM_KEY = 0x0 
OPEN_OPTIONS = 0x2000 
TRACE = 0x0 

LINKS = 41 
MAX_SAPS = 4 
MAX_G_SAPS = 0 
USERS = 4 
TI_TICK_G1 = 255 
T1_TICK_G1 = 15 
T2_TICK_G1 =3 
TI_TICK_G2 = 255 
T1_TICK_G2 = 25 
T2_TICK_G2 = 10 
IPACKETS = 250 
UIPACKETS = 100 
MAXTRANSMITS = 6 
MINTRANSMITS = 2 
TCBS = 64 

GDTS = 30 
ELEMENTS = 800 





Continued on next page. 
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Figure 27 Extended Services Token-Ring PROTOCOL.INI file for LANSUP (part 2) 


[IBMTOK_nif] 
DriverName = IBMTOK$ 
PRIMARY 
MAXTRANSMITS = 12 
RECVBUFS = 2 
RECVBUFSIZE = 256 


tierce _(a308 For Token-Ring 16/4 boards, "Link Support buffer size" 
- in NET.CFG must be 6 bytes less than this number. 


Note: This example uses universally-administered addresses, so a node address is not 
specified in PROTOCOL.INI. 














LANSUP Files from a LAN Requester Environment 
These files came from a computer with the following software installed: 
+ OS/2 v2.0 
+ LAN Requester v2.0 
+ NetWare Requester v2.01 with LANSUP 


Figure Figure 28 and Figure 29 illustrate a CONFIG.SYS file for this 
environment. 
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Figure 28 LAN Requester Token-Ring CONFIG.SYS file for LANSUP (part 1) 


LIBPATH=C:\MUGLIB\DLL;C:\IBMLAN\N ETLIB;.;C:\OS2\DLL;C:\OS2\MDO$S;C:\;C:\0S2\ 
APPS\DLL;C:\ANETWARE;C:\ibmcom\dll; 
SET 
PATH=C:\IBMLAN\NETPROG;C:\MUGLIB;C:\0S2;CA\OS2\SYSTEM;C:\OS2\MDOS\WINOS2 
;C \OS2\INSTALL;C:\;C:\OS2\MDOS;C:\OS2\APPS;LAOS2;P:\0S2;C:\NETWARE; 
SET 
DPATH=C:\IBMLAN\NETPROG;C:\IBMLAN;C:\MUGLIB;CAOS2;CA\O0S2\SYSTEM; C:\O0S2\ 
MDOS\WINOS2;C:\OS2\INSTALL;C:\;C:\OS2\BITMAP;C:\0S2\MDOS;C\0S2\APPS;L\OS2 
C:ANETWARE;C:\ibmcom; 

Protocol Manager 


j is loaded by 
DEVICE=C:\ibmcom\lanmsgdd.os2 /I:C:\ibmcom LAN Services. 
DEVICE=C:\ibmcom\protman.os2 /I:C:\ibmcom 
DEVICE=C:\ibmcom\protocol|\LANDD.OS2 — For TOKEN LANSUP environments, 





DEVICE=C:\ibmcom\protoco\LANDLLDD.OS2 — you must run the IBM LAPS program 


and install 802.2 support to load these 


. components. 
CODEPAGE=437,850 The LAN Services 


DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP NETBIOS driver loads. 
DEVICE=C:\IBMCOM\PROTOCOL\NETBEUI.OS2 
DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2 


DEVICE=C:\IBMLAN\NETPROG\RDRHELP.200 NDIS TOKEN 
driver loads. 
Continued on next page. 
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Figure 29 LAN Requester Token-Ring CONFIG.SYS file for LANSUP (part 2) 


REM --- NetWare Requester statements BEGIN --- .- 








SET NWLANGUAGE=ENGLISH NetWare 
DEVICE=C:\NETWAREALSL.SYS Requester 
RUN=C:\NETWARE\DDAEMON.EXE statements 
DEVICE=C:\NETWARE\LANSUP.SYS are loaded 
DEVICE=C:\NETWARE\ROUTE.SYS by the 
DEVICE=C:\NETWARE\IPX.SYS Requester 
DEVICE=C:\NETWARE\SPX.SYS installation. 
RUN=C:\NETWARE\SPDAEMON.EXE 





rem DEVICE=C:\ANETWARE\NMPIPE.SYS 
rem DEVICE=C:\NETWARE\NPSERVER.SYS Yy 

rem RUN=C:\NETWARE\NPDAEMON.EXE 
DEVICE=C:\NETWARE\NWREQ.SYS 

IFS=C:\NETWARE\NWIFS.IFS * 
RUN=C:\NETWARE\NWDAEMON.EXE 

rem DEVICE=C:\NETWARE\NETBIOS.SYS 

rem RUN=C:\NETWARE\NBDAEMON.EXE 

DEVICE=C:\NETWARE\VIPX.SYS 

DEVICE=C:\NETWARE\VSHELL.SYS PRIVATE 

REM --- NetWare Requester statements END --- 





LAN Services file 
IFS=CA\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN /N system loads. 


DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2 
RUN=C:\IBMLAN\NETPROG\LSDAEMON.EXE 
RUN=C:\ibmcom\protocol\landll.exe 
RUN=C:\ibmcom\protocol\netbind.exe 
RUN=C:\ibmcom\lanmsgex.exe 


Load order requirements 


1. NWIFS.IFS 
2. NETWKSTA.200 
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Figure 30 illustrates a NET.CFG for the example LAN Requester 
environment. 


Figure 30 LAN Requester Token-Ring NET.CFG file for LANSUP 





link driver lansup I Set node address. Use the 


o a 10005a8c62d4M Bind aTOKEN frame rte nica to the board 
rame token-ring type to LANSUP. y the vendor. 


Put a blank line at 
the end of the file. 








Figure 31 and Figure 32 illustrate a PROTOCOL.INI for the example LAN 
Requester environment. 
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Figure 31 LAN Requester Token-Ring PROTOCOL.INI file for LANSUP (part 1) 


[PROT_MAN] 
DriverName = PROTMAN$ 
[IBMLXCFG] 
IBMTOK_nif = IBMTOK.nif 
NETBEUL nif = NETBEUL. nif 
LANDD_ nif = LANDD.nif 


i LAN Services NetBIOS 
[NETBE Unit ° protocol is configured. 
DriverName = netbeui$ NDIS TOKEN 
Bindings = IBMTOK_nif driver is bound. 
ETHERAND_TYPE = "I" 


USEADDRREV = "YES" 
SESSIONS = 40 

NCBS = 95 

NAMES = 21 
SELECTORS = 5 
USEMAXDATAGRAM = "NO" 
ADAPTRATE = 1000 
WINDOWERRORS = 0 

TI = 30000 

T1 = 500 

T2 = 200 

MAXIN = 1 

MAXOUT = 1 
NETBIOSTIMEOUT = 500 
NETBIOSRETRIES = 8 
NAMECACHE = 0 
PIGGYBACKACKS = 1 
DATAGRAMPACKETS = 2 
PACKETS = 350 
PIPELINE = 5 
MAXTRANSMITS = 6 
MINTRANSMITS = 2 


DLCRETRIES =5 Continued on next page. 
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Figure 32 LAN Requester Token-Ring PROTOCOL.INI file for LANSUP (part 2) 


[LANDD_ nif] 


DriverName = LANDD$ 
Bindings = IBMTOK_unif NDIS TOKEN driver is bound. 
ETHERAND_TYPE = "I" 


SYSTEM_KEY = 0x0 
OPEN_OPTIONS = 0x2000 
TRACE = 0x0 

LINKS = 8 

MAX_SAPS = 3 
MAX_G_SAPS = 0 
USERS = 3 
TITICK_G1 = 255 
T1_TICK_G1 = 15 
T2_TICK_G1 =3 
TI_TICK_G2 = 255 
T1_TICK_G2 = 25 
T2_TICK_G2 = 10 
IPACKETS = 250 
UIPACKETS = 100 
MAXTRANSMITS = 6 
MINTRANSMITS = 2 
TCBS = 64 GDTS = 30 
ELEMENTS = 800 


;*--------------- MAC SECTION ----------------- i 
[IBMTOK_ nif] 

DriverName = IBMTOK$ 

PRIMARY 

MAXTRANSMITS = 12 

RECVBUFS = 2 

RECVBUFSIZE = 256 

XMITBUFS = 1 


Note: You are not required to change anything in PROTOCOL.INI to set up LANSUP. 
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Setting Up Named Pipes and NetBIOS 
Protocols 


Topic 





“About the Protocol Support in the NetWare Requester” on page 113 
“Setting Up Named Pipes for OS/2” on page 116 

“Setting Up Named Pipes for DOS and Windows’ on page 123 
“Setting Up NetBIOS for OS/2” on page 125 


“Setting Up NetBIOS for DOS and Windows’ on page 145 


This chapter explains how to install and configure the Named Pipes and 
NetBIOS protocols. 


About the Protocol Support in the NetWare Requester 
Novell provides four kinds of protocol support with the NetWare Requester 
for OS/2: 

+ IPX 

+ SPX 

+ Named Pipes 

+ NetBIOS (emulation) 
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NetWare servers and clients use IPX as the primary protocol to communicate 
with each other. They also use SPX for some communications, such as 
communications between a workstation running NPRINTER and a NetWare 
print server. Support for IPX on the workstation is automatically installed 
when you install the NetWare workstation software. 


The SPX, NetBIOS, and Named Pipes protocols are provided by Novell so 
that NetWare clients and servers can also function as: 


¢ Distributed application clients and servers 
+ Non-NetWare network clients and servers 


+ Terminals connected to mainframes or minicomputers 


For example, the Lotus Notes distributed application uses NetBIOS for 
communications; Microsoft SQL Server uses Named Pipes. LANServer 
networks use NetBIOS, and many Communications Manager connections to 
a mainframe also use NetBIOS. 


Other protocols not provided with the NetWare Workstation for OS/2 can also 
be used for these purposes. For example, the TCP/IP protocol provided by 
Novell's LAN Workplace for OS/2 is commonly used for connections to 
UNIX hosts. These other protocols are not discussed in this book. 


Figure 33 illustrates the components of a distributed application network. 
Note that protocol support software usually must be installed independent of 
installing the distributed application software. 
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Figure 33 Protocol software is separate from distributed application software 


Distributed 
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OS/2 


Protocol 
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Distributed 
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Distributed 
application 
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support 
Os/2 


Distributed 
application 


server E] Provided by Novell 


Several different protocols can be installed on the same computer at the same 
time. All of these protocols can use the same network cabling, though each 
protocol may communicate on a completely separate logical network. Figure 
34 on page 116 shows how a NetWare network and a distributed application 
network share cabling. 
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Figure 34 A distributed application on a NetWare network 


e NetWare client e NetWare client 


e Distributed application e Distributed application 
client server 









OS/2 
workstation 


OS/2 
workstation 


NetWare 
server 


Setting Up Named Pipes for OS/2 


You must install the Named Pipes support you need on each computer that will 
use Named Pipes on the network. In most cases, you must also set certain 


configuration options for the protocol. 


Installing Named Pipes for OS/2 


Named Pipes support between sessions on a single OS/2 workstation is 


provided with the OS/2 operating system. 


However, if you need OS/2 sessions to communicate with other computers on 
the network using Named Pipes, you must install remote Named Pipes 


support. 


“Protocol Requests from OS/2 Sessions” on page 251 explains how Novell's 


Named Pipes support for OS/2 works. 
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Prerequisite 


Procedures 


Install your Named Pipes distributed application. See the documentation 
for your application. 


Start the NetWare Requester installation program. 


If the Requester is not installed, you can start the program from your 
WSOS2_1 diskette. Type INSTALL. You can install the Requester at the 
same time as you install Named Pipes. 


If the Requester is already installed, you can start the program by 
choosing the "Installation" icon from the "Novell" group on your desktop. 


Choose "Requester on Workstation" from the "Installation" menu. 
Verify the target and source directory and choose "OK." 


Select an action from the "Requester Installation" screen based on 
whether the Requester is installed: 


4a Ifthe Requester is not installed, select "Edit CONFIG.SYS and Copy 
All Files . . . " and choose "OK." 


4b Ifthe Requester is already installed, select "Only Edit CONFIG.SYS 
..." and choose "OK." 


Select the ODI driver for your network board and choose "Continue. . ." 


Select your preferences for NetWare support for DOS and Windows 
applications and choose "Continue . . ." 


Select "Remote Named Pipes Support." 
Set up your workstation as a Named Pipes client or server. 


8a Choose "Client Support Only" to set up your workstation as a Named 
Pipes application client. 


If your workstation will be a client for the SQL Server distributed 
application, you must do some additional steps. After completing this 
section and “Configuring Named Pipes for OS/2” on page 118, you 
will be told to go to the “Special Instructions for SQL Client 
Workstations” on page 122. 


8b Choose "Client and Server Support" and type a machine name to set 
up your workstation as a Named Pipes application server. 


Choose "Help" to see the syntax requirements for the machine name. 
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9 
10 


11 


Choose "Save..." 
Verify the filename and location and choose "OK." 


If you have not previously installed the Requester, the "Copy Requester 
Files" screen appears. Continue with Step 11. 


If you have previously installed the Requester, the main installation menu 
appears. Go to “Configuring Named Pipes for OS/2” on page 118. 


Choose "Copy" and follow the screens to finish installing the Requester. 


When the main menu returns, go to “Configuring Named Pipes for OS/2” 
on page 118. 


Configuring Named Pipes for OS/2 


Prerequisite 


Procedures 


Novell's Named Pipes support comes with default configuration settings. You 
may want to customize the configuration. Follow the instructions below to 


+ 


+ 


Determine whether you need to change the default configuration for 
Named Pipes and SPX, and 


Change the configuration if necessary. 


You can change the configuration for such features as 


+ 
+ 


+ 


2 
3 


Available number of client and server sessions 
Number of service threads available for Named Pipes communication 


Number of SPX sessions available for Named Pipes and other SPX 
communication (Named Pipes uses SPX) 


The NetWare Requester for OS/2 must be installed. If it is not installed, 
do the steps in “Installing Named Pipes for OS/2” on page 116. 


Start the NetWare Requester installation program. 


The program may already be running if you just installed Named Pipes 
support. If the program is not running, start it by choosing the 
"Installation" icon from the "Novell" group on your desktop. 


Choose "This workstation . . ." from the "Configuration" menu. 


Verify the location of the NET.CFG file and choose "Edit." 
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The "Edit NET.CFG" window appears. See Figure 35 on page 120. You 
can cut and and paste text from the help window at the bottom of the 
screen to the "Current NET.CFG File Contents" window. Use the 
following keys: 


Table 11 Key definitions for the NET.CFG window 


To do this... Use these keys.... 





Highlight text Click and drag with the mouse, or move the 
cursor with the arrow keys while holding down 
the <Shift> key 





Copy text <Ctrl><Insert> 





Cut text (text will reappear <Shift><Delete> 
the next time you refresh the 








window) 
Paste text <Shift><Insert> 
Delete text (deleted text <Ctrl><Delete> 


cannot be pasted) 
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Figure 35 Editing NET.CFG for Named Pipes 





















Select a 
NET.CFG option, 
setting, or topic. 


aa Type NET.CFG 
options and 
settings here. 


Save your 
configuration or 
change your mind. 

















| Edit 


he NET.CFG file for this workstation 


NET.CFG Options Current NET.CFG File Contents 
remove server memory | 
server memory 
Token-Ring source routing 
def 
gbr 
mbr 
nodes 
board 
Named Pipes 
server sessions 
service threads 
Virtual MLID for LAN Sharin 
virtual board size 





CLIENT SESSIONS number 





Replace "number" with a number from 3 to 128. 
Default = 16 sessions 


You need at least one client session for each connection from an OS/2 
application to a Named Pipes server. The default of 16 sessions is 
usually adequate, except with applications that use many Named Pipes. 







PA Read online 
help for the topic 
you selected. 


ES Select the type 
of information you 
want to see. 






4 Select "Named Pipes" from the "NET.CFG Options" box on the left of 
your screen. 


5 Determine whether to change the configuration for the "client sessions", 
"server sessions" and "service threads" settings under "Named Pipes." 
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If you decide not to change the configuration for a setting, no action is 
required for that setting. 


5a Select one of the three settings. 
For example, select "client sessions." 


5b Read the help window at the bottom of the screen to determine 
whether to change the configuration for the setting. 


You can choose the "Usage," "Description" and "Example" buttons 
on the right of your screen to see more information about the setting 
you've selected. 


5c (Optional) If you decide to change the configuration, type the 
configuration lines (as shown in the "Usage" help window) into the 
"Current NET.CFG File Contents" box. 


IMPORTANT: You must follow the format requirements explained in the 
"Format of NET.CFG Options" topic. To see these requirements, select this 
topic from the "NET.CFG Options" box and choose the "Usage" button. 


Repeat Step 5a through Step Sc for each setting. 


6 Select "Protocol Stack SPX" from the "NET.CFG Options" box on the left 
of your screen. 


7 Select the "sessions" setting under "Protocol Stack SPX." 


8 Read the help window at the bottom of the screen to determine whether 
to change the configuration for "sessions." 


You can choose the "Usage," "Description" and "Example" buttons on the 
right of your screen to see more information about the setting you've 
selected. 


9 (Optional) If you decide to change the configuration, type the 
configuration lines (as shown in the "Usage" help window) into the 
"Current NET.CFG File Contents" box. 


If you decide not to change the configuration, no action is required for this 
step. 


IMPORTANT: You must follow the format requirements explained in the "Format 
of NET.CFG Options" topic. To see these requirements, select this topic from the 
"NET.CFG Options" box and choose the "Usage" button. 


10 Choose "Save." 
41 Exit the NetWare Requester installation program. 
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11a If your workstation will be a client for the SQL Server distributed 
application, close the installation program and go to “Special 
Instructions for SQL Client Workstations” on page 122. Do not 
reboot yet. 


141b If your workstation will not be a SQL client, close the installation 
program and use the OS/2 "Shutdown" feature to reboot your 
computer. 


Special Instructions for SQL Client Workstations 


Procedures 


Client workstations for the SQL Server distributed application must use 
special versions of the NETAPI.DLL and NETOEM.DLL files. These files are 
contained in a \SQL directory on the WSOS2_1/ diskette. 


The \SQL NETAPI.DLL contains everything the default NETAPI.DLL 
contains (including the NETBIOS calls), as well as some additional function 
calls required by SQL clients. 


Complete the following steps to copy these files to the correct location: 


1 Insert the WSOS2_/ diskette into a floppy drive. 
2 Copy the NETAPI.DLL and NETOEM.DLL files from the \SQL 


subdirectory on the diskette to the directory where the SQL front end 
executable is located. 


For example, if you are using a Microsoft/Sybase SQL, the Novell files 
would need to be copied to the SQL\BINP subdirectory where SAF.EXE 
is located. 


You can copy the files by dragging them on the desktop or by typing a 
command such as the following at an OS/2 command line: 


COPY A:\SQL\*.DLL C:\SQL\BINP 


WARNING: Be sure to copy the files from the \SQL directory, since there is also 
a NETAPI.DLL in the root directory on the diskette. The two NETAPI.DLL files are 
not the same. 


The \SQL NETAPI.DLL emulates certain features of LAN Server support 
that are required for SQL clients. However, this NETAPI.DLL does not 
provide full LAN Server support. An application which assumes full 
LAN Server support if it finds any LAN Server calls may not run 


properly. 
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3 Open your CONFIG.SYS file in a text editor. 


4 Type a dot and a semicolon (. ;) as the first entry in the LIBPATH 
statement. 


For example, the first part of your LIBPATH might read: 
LIBPATH=.;C:\OS2\DLL;C:\; 


The dot and semicolon tell OS/2 to look for Dynamic Link Libraries 
(DLLs) in the current directory first. 


5 Save and exit the CONFIG.SYS file. 
6 Use the OS/2 "Shutdown" feature to reboot your computer. 


When you execute the SAF.EXE, OS/2 will then use the NETAPI.DLL in 
the same directory. 


Setting Up Named Pipes for DOS and Windows 


Prerequisites 


This section applies to virtual DOS and Windows sessions only. See the 
NetWare Workstation for DOS and Windows manual to set up Named Pipes 
on an actual DOS or Windows workstation. 


Virtual DOS and Windows sessions can function as Named Pipes clients; they 
cannot function as Named Pipes servers. 


If you've met the following prerequisites, you automatically have Named 
Pipes support for virtual DOS sessions: 


Q) Enable IPX support for virtual sessions. Chapter 3, “Network Access 
from Virtual DOS and Windows,” on page 19 explains how to do this. 


Q Enable Named Pipes support for OS/2 sessions. “Setting Up Named Pipes 
for OS/2” on page 116 explains how to do this. 


IMPORTANT: Do not load the Named Pipes extender in virtual DOS and 
Windows sessions. 
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If you want Named Pipes support in any of the following situations, you must 
also see the sections shown: 





If you want Named Pipes for Go to 








Virtual Windows sessions “For Virtual Windows Named Pipes Clients” on 
page 124 

Sessions with the “For Sessions with DOS_STARTUP_DRIVE Set” 

DOS_STARTUP_DRIVE on page 124 

feature 





For Virtual Windows Named Pipes Clients 


Copy the NETAPI.DLL file from the \WINDOWS.NP subdirectory on the 
WSOS2_1 diskette to one of the following locations on your hard disk: 


+ The \OS2\MDOS\WINOS2 subdirectory (since this directory contains 
WINOS2.COM) 


+ The \OS2\MDOS\WINOS2\SYSTEM subdirectory (since this directory 
contains the Windows KERNEL.EXE) 


¢ The directory of the application that runs Named Pipes 


WARNING: This NETAPI.DLL is a Windows file, not an OS/2 file, and is provided 
specifically for Named Pipes Windows clients. Do not copy it over the NETAPI.DLL 
in the \NETWARE directory. 


“Protocol Requests from DOS/Windows Sessions” on page 262 explains how 
Named Pipes support works for virtual DOS and Windows clients. 


For Sessions with DOS_STARTUP_DRIVE Set 


Sessions set with DOS_STARTUP_DRIVE boot from a version of DOS other 
than the one included in OS/2. The OS/2 online "Master Help Index" explains 
more about the DOS_STARTUP_DRIVE feature. 


If you are using DOS_STARTUP_DRIVE to boot a session, you do not need 
to get your Named Pipes support from Novell. Instead, you can load the 
FSFILTER.SYS driver provided by OS/2. 


Load the FSFILTER.SYS driver in the CONFIG.SYS file for the 
DOS_STARTUP_DRIVE session. (The CONFIG.SYS file is bound into the 
image file you boot the session from. See your OS/2 documentation.) 
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To load the FSFILTER.SYS driver, do the following: 


Procedures 


1 Open the CONFIG.SYS file for the DOS STARTUP_DRIVE session in 
a text editor. 


2 Ona new line in the file, type a line to load FSFILTER.SYS. 
For example, you might type: 
DEVICE=C: \OS2\MDOS\FSFILTER.SYS 

3 Save and exit the CONFIG.SYS file. 


See your OS/2 documentation for more information about loading 
FSFILTER.SYS in your CONFIG.SYS. 


IMPORTANT: Do not load the Novell Named Pipes Extender for DOS in the 
DOS_STARTUP_DRIVE session. It will conflict with the OS/2 Named Pipes driver. 


Setting Up NetBIOS for OS/2 


Novell NetWare Requester provides a NetBIOS driver (NETBIOS.SYS) that 
emulates the NetBIOS protocol. 


The NetBIOS provided by Novell is called an emulator because it does not 
transmit NetBIOS packets on the network. Instead, NetBIOS packets are 
encapsulated in IPX packets, and the IPX packets are transmitted. 


IBM Extended Services and LAN Services provide a native NetBIOS driver 
(NETBEUI.OS2) rather than an emulation. 


This chapter explains how to set up Novell's NetBIOS driver. It also explains 
how to configure your workstation for NetBIOS when you also have IBM's 
Extended Services or LAN Services NetBIOS installed. 


“Protocol Requests from OS/2 Sessions” on page 251 explains more about 
how Novell's NetBIOS driver works. 





Topics 





“Determining Which NetBIOS Drivers to Set Up” on page 126 
“Setting Up the Novell NetBIOS Driver” on page 130 
“Configuring NETBIOS.OS2 with PROTOCOL.INI” on page 136 


“Configuring NETWKSTA.200 with IBMLAN.INI” on page 140 
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Determining Which NetBIOS Drivers to Set Up 


Use this section to determine whether your application needs access to the 
Novell NETBIOS.SYS driver, the IBM NETBEUI.OS2 driver, or both. 


Which drivers your application can access depends on 


+ Whether you have Extended Services or LAN Services installed on your 
workstation, and 


+ The interface used by your application. 


Your Installed IBM Software 


NetBIOS support is provided with 
+ Extended Services 


Extended Services NetBIOS support is included in the LAPS programs. 
NetBIOS-related pieces of LAPS are 


+ NETAPI.DLL 
+ ACSNETB.DLL 
+ NETBIOS.OS2 
+ NETBEUI.OS2 
+ LANPDD 
+ LANVDD 

+ LAN Services 


LAN Services NetBIOS support is included in the LAPS program and in 
NETWKSTA.200. 


Identify whether you have Extended Services, LAN Services, or both. Then 
go to the next section. 


NOTE: When this section refers to the NetBIOS support available with a particular 
IBM product (such as Extended Services), we assume the product includes the 
files we list. By default, the files shown here are included in Extended Services and 
LAN Services packages. By default, LAPS is included in both packages, although 
different NetBIOS components are actually used in each package. 


However, the files shown may also be included in other packages. For example, 
you may have received the IBM LAPS program without receiving Extended 
Services. 
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In this case, you might actually have the NetBIOS support usually provided by 
Extended Services without having the whole Extended Services product. Work with 
IBM to resolve any questions about what IBM files you have relating to NetBIOS 
support. 


Your Application's Interface 


OS/2 NetBIOS applications use Dynamic Link Libraries (DLLs) to interface 
with NetBIOS drivers. Which DLL your application uses depends on which 
NetBIOS interface standard your application follows: 


+ ACSNETB.DLL 


This is IBM's NetBIOS 3.0 (NB30) interface. The NB30 interface was 
introduced by IBM in OS/2 v2.0, so applications written before OS/2 v2.0 
most likely cannot use it. 


¢ The NETAPI.DLL 


This is the original OS/2 NetBIOS Submit interface. This interface was 
supported by LAN Manager and LAN Server before OS/2 v2.0 was 
released. 


You can run applications that use different interfaces at the same time, as long 
as you have the support for each interface installed and configured. For 
example, you can run an NB30 application and a NetBIOS Submit application 
on the same workstation. 


See the documentation for your application to determine which NetBIOS 
interface it uses, then follow the flow charts in Figure 36 on page 128 or Figure 
37 on page 129 to see 


+ Whether the IBM or Novell NetBIOS driver can be accessed by your 
application, and 


+ Where to find instructions on setting up the drivers. 
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Figure 36 Determine what NetBIOS support you have for NetBIOS 3.0 (NB30) applications 
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Figure 37 
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Determine what NetBIOS support you have for NetBIOS Submit applications 
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Setting Up the Novell NetBIOS Driver 


Do this section only if you were directed here from the flow chart in Figure 37 
on page 129 because you 


+ Have a NetBIOS Submit application 

+ Have Extended Services 

+ Do not have LAN Services 
As Figure 38 shows, the Novell NetBIOS driver interfaces with Novell's 
NETAPI.DLL file when you do not have Extended Services. 


Figure 38 NetBIOS Requests through Novell's NetBIOS Driver 


OS/2 applications that make NetBIOS Submit calls 


NETAPI.DLL (Novell) 








NETBIOS 


IPX 


As Figure 39 on page 131 shows, if you are using Extended Services, the 
NETAPI.DLL is the one from the Extended Services package. This 
NETAPI.DLL interfaces with a NETSUB.DLL file from Novell, which in turn 
works with the Novell NetBIOS driver. 
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Figure 39 NetBIOS Requests through Novell's NetBIOS Driver with Extended Services installed 
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Follow the procedures in the next section, Installing the Driver, to use the 
Novell NetBIOS driver. The procedures apply whether or not you have 
Extended Services. 


IMPORTANT: If you are using Extended Services, you must get an updated 
NETAPI.DLL file from IBM. The one shipped with base Extended Services 1.0 does 
not provide the intended NetBIOS support. 


Installing the Driver 


Prerequisites 


Q) Install Extended Services if you have it. See the IBM documentation for 
Extended Services. 


Q) Install your NetBIOS application. See the documentation for your 
application. 
Procedures 


NOTE: You can install the NetWare Requester from this procedure. 


You must install the Novell NetBIOS driver on each computer that will use 
Novell NetBIOS on the network. 


4 Start the NetWare Requester installation program. 


If the Requester is not installed, you can start the program from your 
WSOS2_1 diskette. Type INSTALL. You can install the Requester at the 
same time as you install NetBIOS. 
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Configuring the Driver 


If the Requester is already installed, you can start the program by 
choosing the "Installation" icon from the "Novell" group on your desktop. 


Choose "Requester on Workstation" from the "Installation" menu. 
Verify the target and source directory and choose "OK." 


Select an action from the "Requester Installation" screen based on 
whether the Requester is installed: 


4a Ifthe Requester is not installed, select "Edit CONFIG.SYS and Copy 
All Files . . . " and choose "OK." 


4b Ifthe Requester is already installed, select "Only Edit CONFIG.SYS 
..." and choose "OK." 


Select the ODI driver for your network board and choose "Continue. . ." 


Select your preferences for NetWare support for DOS and Windows 
applications and choose "Continue . . ." 


Select "NetBIOS Emulation for OS/2 Sessions." 
Choose "Save..." 
Verify the filename and location and choose "OK." 


If you have not previously installed the Requester, the "Copy Requester 
Files" screen appears. Continue with “Choose "Copy" and follow the 
screens to finish installing the Requester.” on page 132. 


If you have previously installed the Requester, the main installation menu 
appears. Go to “Configuring the Driver” on page 132. 


Choose "Copy" and follow the screens to finish installing the Requester. 


When the main menu returns, go to “Configuring the Driver” on page 
132. 


Novell's NetBIOS driver comes with default configuration settings. You may 
want to customize the configuration. Follow the instructions below to 


+ 


+ 


Determine whether you need to change the default configuration for 
NetWare NetBIOS, and 


Change the configuration if necessary. 
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You can change the configuration to manage such features as 
+ Names 
¢ Sessions 


+ Commands 


If you do not know what NetBIOS names, sessions, and commands are, see 
the documentation for your NetBIOS application. 
Prerequisite 
Q The NetWare Requester for OS/2 must be installed. If it is not installed, 
do the steps in “Installing the Driver” on page 131. 
Procedures 
1 Start the NetWare Requester Installation program. 


The program may already be running if you just installed the NetBIOS 
driver. 


If the program is not running, start it by choosing the "Installation" icon 
from the "Novell" group on your desktop. 


2 Choose "This workstation .. ." from the "Configuration" menu. 
3 Verify the location of the NET.CFG file and choose "Edit." 


The "Edit NET.CFG" window appears. See Figure 40 on page 134. You 
can cut and and paste text from the help window at the bottom of the 
screen to the "Current NET.CFG File Contents" window. Use the 
following keys: 


Table 12 Key definitions for the NET.CFG window 





To do this... Use these keys.... 





Highlight text Click and drag with the mouse, or move the 
cursor with the arrow keys while holding down 
the <Shift> key 





Copy text <Ctrl><Insert> 





Cut text (text willreappearthe <Shift><Delete> 
next time you refresh the 
window) 
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To do this... Use these keys.... 





Paste text <Shift><Insert> 





Delete text (deleted text <Ctrl><Delete> 
cannot be pasted) 


Figure 40 Editing NET.CFG for NetBIOS 


GA Type NET.CFG Save your 
NET.CFG option, options and configuration or 
setting, or topic. settings here. change your mind. 


| Edit the NET.CFG file for this workstation 


NET.CFG Options Current NET.CFG File Contents 
request retries 
sessions 

NetWare NetBIOS 
broadcast count 
broadcast delay 
commands 
internet 
listen timeout 
names 
retry count 
retry delay 
sessions 
verify timeout 


ABORT TIMEOUT number 


Replace "number" with a number of milliseconds greater than 500. 
Default = 30,000 milliseconds 


If you change this setting, you must also change the LISTEN TIMEOUT 
and YERIFY TIMEOUT settings. The ratio between these three settings 
must remain the same. 


PA Read online EZ Select the type 
help for the topic of information you 
you selected. want to see. 
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4 


Select "NetWare NetBIOS" from the "NET.CFG Options" box on the left 
of your screen. 


Determine whether to change the configuration for the settings under 
"NetWare NetBIOS." 


If you decide not to change the configuration for a setting, no action is 
required for that setting. 


5a Select one of the settings. 
For example, select "abort timeout." 


5b Read the help window at the bottom of the screen to determine 
whether to change the configuration for the setting. 


You can choose the "Usage," "Description," and "Example" buttons 
on the right of your screen to see more information about the setting 
you've selected. 


5c (Optional) If you decide to change the configuration, type the 
configuration lines (as shown in the "Usage" help window) into the 
"Current NET.CFG File Contents" box. 


IMPORTANT: You must follow the format requirements explained in the 
"Format of NET.CFG Options" topic. To see these requirements, select this 
topic from the "NET.CFG Options" box and choose the "Usage" button. 


Repeat Step 5a through Step Sc for each setting. 
Choose "Save." 
Exit the NetWare Requester installation program. 


If your NetBIOS application will not access the IBM NetBIOS driver, use 
the OS/2 "Shutdown" feature to reboot your computer. 


If your NetBIOS application will access the IBM NetBIOS driver, do not 
reboot. Instead, configure the IBM driver as instructed in one of the 
following sections: 


+ “Configuring NETBIOS.OS2 with PROTOCOL.INI’ on page 136 
+ “Configuring NETWKSTA.200 with IBMLAN.INI” on page 140 


If you do not know which of these two sections to read, go to 
“Determining Which NetBIOS Drivers to Set Up” on page 126. 
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Configuring NETBIOS.OS2 with PROTOCOL.INI 


Do this section only if you were directed here from the flow chart in Figure 36 
on page 128 because you 


+ Have the LAPS program, and 
+ Have a NetBIOS 3.0 application. 


As Figure 41 shows, IBM's ACSNETB.DLL interfaces with NETBIOS.OS2, 


also provided by IBM. NETBIOS.OS2 can be configured to pass NetBIOS 
requests to either 


+ NETBEUI.OS2, IBM's NetBIOS driver, or 
+ NETBIOS.SYS, Novell's NetBIOS driver 


This section explains how to configure NETBIOS.OS2 to support both 
NetBIOS drivers simultaneously or to support only Novell's driver. 


If you only want to use IBM's NetBIOS driver, you do not need to configure. 
By default, NETBIOS.OS2 talks only to NETBEUILOS2. 


Figure 41 NetBIOS Requests through NETBIOS.OS2 
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NETBEUI (IBM) $=% NETBIOS.OS2 (IBM) $=% NETBIOS (Novell) 
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Prerequisites 


Procedures 


Install Extended Services with NetBIOS support. Verify that you can get 
a NetBIOS connection. 


Install LAN Services (NetBIOS support is installed by default). Verify 
that you can get a LAN connection. 


Do the steps in “Setting Up the Novell NetBIOS Driver” on page 130 to 
install the NetWare Requester with the Novell NetBIOS driver. 


In this procedure, you edit the PROTOCOL.INI file to define a virtual adapter 
for the Novell and IBM NetBIOS drivers. 


41 Open the PROTOCOL.INI file in a text editor. 


For example, to use the OS/2 System Editor at the command line, you 
would type: 


E C:\IBMCOM\PROTOCOL. INI 

PROTOCOL.INI is located in the \IBMCOM directory. 
Find the following line: 

[NETBIOS] 


If the [NETBIOS] line does not exist, type the line at the end of the 
PROTOCOL.INI file, exactly as shown. 


On a new line under [NETBIOS], type the following line: 
DriverName = NETBIOS$ 


The line must be indented at least one space and must follow other 
formatting requirements for IBMLAN.INI. NETBIOS$ is the device 
name of NETBIOS.OS2. 


If the line already exists, go to the next step. 


On a new line under the DriverName line, type lines assigning adapter 
numbers to the IBM and Novell NetBIOS drivers. 


To allow NB30 NetBIOS applications to use only Novell's NetBIOS 
driver, add a line for Novell's NetBIOS. 


To allow NB30 applications to use both Novell and IBM drivers, add 
another line for IBM's NetBIOS. 
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NOTE: When you define the Novell NetBIOS network, your default definition for 
the IBM NetBIOS network is no longer defined. So, if you are going to use IBM 
NetBIOS driver, you will also need to add a line for the IBM network. 


Each line you add should look similar to the following: 
ADAPTERa = b,c,sessions, commands, names 


NOTE: If you have existing ADAPTER lines, leave them. 


Replace the variables in the line with values shown in the following chart: 


Table 13 Paremeters for defining dual NetBIOS in PROTOCOL.INI 











Variable Meaning of variable 

ADAPTER Adapter is a key word for NETBIOS.OS2. It is not case-sensitive. 

a Replace a with a number from 0 to 3. This is the adapter number used by the 
application. 


When specifying an adapter number: 


+ Do not use the same number that is used in any other adapter statements. Each 
adapter number can only be defined to one NetBIOS driver. 


+ Do not skip adapter numbers. For example, if you have an existing adapter 
statement that uses ADAPTERO, use ADAPTER1 for your next adapter statement. 





b Replace b with the device name for the NetBIOS driver. NETBIOS.OS2 recognizes this 
name when determining which driver to pass NetBIOS calls to. 


+ Replace b with IPXNB$ for the Novell NetBIOS driver. 
+ Replace b with NETBEUI$ for the IBM NetBIOS driver. 





c Replace c with a number from 0 to 3. This number is the virtual adapter number used 
by the target NetBIOS driver. 


+ For Novell's NetBIOS driver, always specify 0. 


+ For IBM's NetBIOS driver, specify whichever virtual adapter you want used. See the 
Extended Services documentation on NETBEUI.OS2 for more information on how 
it uses virtual adapters. 
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Variable 





Meaning of variable 





sessions 


Replace sessions with the number of NetBIOS sessions you want allocated to NetBIOS 
3.0 applications. This number specifies the maximum number of sessions that can be 
active between NETBIOS.OS2 and Novell's NetBIOS driver. 


Novell's NetBIOS driver is configured with the sessions setting in the NET.CFG file. The 
number of sessions actually allocated to the application is either the NET.CFG value or 
the value on this line of the PROTOCOL.INI, whichever is lowest. 


For example, if you set 64 sessions in NET.CFG, and the value on this line is only 48, 
NetBIOS 3.0 applications will only be able to use 48 sessions. 


If you set 30 sessions in NET.CFG and the value on this line is 50, NetBIOS 3.0 
applications will only be able to use 30 sessions. 





commands 


Replace commands with the number of NetBIOS commands you want allocated to the 
NB30 NetBIOS application. This number specifies the maximum number of commands 
that can be active between NETBIOS.OS2 and Novell's NetBIOS driver. 


Novell's NetBIOS driver is configured with the commands setting in the NET.CFG file. 
The number of commands actually allocated to the application is either the NET.CFG 
value or the value on this line of the PROTOCOL.INI, whichever is lowest. 


For example, if you set 128 commands in NET.CFG, and the value on this line is only 
100, the application will only be able to use 100 commands. 


If you set 80 commands in NET.CFG and the value on this line is 95, the application will 
only be able to use 80 commands. 





names 


Replace names with the number of NetBIOS names you want allocated to the NB30 
application. This number specifies the maximum number of names that can be active 
between NETBIOS.OS2 and Novell's NetBIOS driver. 


Novell's NetBIOS driver is configured with the names setting in the NET.CFG file. The 
number of names actually allocated to the application is either the NET.CFG value or 
the value on this line of the PROTOCOL.INI, whichever is lowest. 


For example, if you set 128 names in NET.CFG, and the value on this line is only 100, 
the application will only be able to use 100 names. 


If you set 80 names in NET.CFG and the value on this line is 95, the application will only 
be able to use 80 names. 


For example, to enable applications to use both the Novell or the IBM 
NetBIOS driver, the lines in your PROTOCOL.INI file might read: 


[NETBIOS] 
DriverName = NETBIOSS 
AdapterO = ipxnb$,0,16,16,8 
Adapterl = netbeuis$,0,32,14,8 
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For more information about defining adapters in NETBIOS.OS2, see 
your Extended Services documentation. 


5 Insert a blank line at the end of the file. 
6 Save the PROTOCOL.INI file and exit your text editor. 


7 Use the "Shutdown" feature from the OS/2 system menu to reboot your 
computer. 


When your computer restarts, your NB30 NetBIOS applications will be 
able to use each driver you defined with an Adapter line. 


Configuring NETWKSTA.200 with IBMLAN.INI 


Do this section only if you were directed here from the flow chart on Figure 
37 on page 129 because you 


+ Have a NetBIOS Submit application, and 
+ Have LAN Services 


As Figure 42 on page 141 shows, NETAPI.DLL interfaces with IBM's 
NETWKSTA.200. The NETAPI.DLL file used is the one provided with LAN 
Services. This happens by default, since the \MUGLIB\DLL directory which 
stores the LAN Services NETAPI.DLL comes earlier in the path than the 
\NETWARE directory which contains the NetWare Requester NETAPI.DLL. 


NETWKSTA.200 can be configured to pass NetBIOS requests to either 
+ NETBEUI.OS2, IBM's NetBIOS driver, or 
+ NETBIOS.SYS, Novell's NetBIOS driver 


This section explains how to configure NETWKSTA.200 to support both 
NetBIOS drivers simultaneously or to support only Novell's driver. 


If you only want to use IBM's NetBIOS driver, you do not need to configure. 
By default, NETWKSTA.200 talks only to NETBEUILOS2. 
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Figure 42 NetBIOS Requests through NETWKSTA.200 
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Q) Install Extended Services if you have it. 


Q) Install LAN Services (NetBIOS support is installed by default). Verify 


that you can get a LAN connection. 


U Do the steps in “Setting Up the Novell NetBIOS Driver” on page 130 to 


install the NetWare Requester with the Novell NetBIOS driver. 


4 Open the IBMLAN.INI file in a text editor. 


For example, to use the OS/2 System Editor at the command line, you 
would type: 


E C:\IBMLAN\IBMLAN. INI 
IBMLAN.INI is located in the \IBMLAN directory on your boot drive. 


2 Find the following line: 


[networks] 


Underneath the [networks] line, you should see a line similar to the 
following defining a particular network as the one using IBM's NetBIOS 
driver, NETBEUI.OS2: 


netl = NETBEUIS,1,4LM10,32,50,14 
This line defines netl as the network using the IBM NetBIOS driver. 
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3 Ifthe IBM driver is defined to netl, change the 1 to a 2. 
The line should look like the following: 
net2 = NETBEUIS,1,LM10,32,50,14 


You must change the IBM driver because the Novell driver has to be 
defined to net] in order for dual NetBIOS to work. 


4 Underneath any existing net statements, type a line assigning network 
number | to the Novell NetBIOS driver. 


NOTE: A network for IBM NetBIOS is defined by default in both LAN Requester 
and LAN Server. If you want NetBIOS Submit applications to only use Novell's 
NetBIOS driver, comment out the line for the IBM driver with a semicolon. 


The line must be indented at least one space and must follow other 
formatting requirements for IBMLAN.INI. 


The Novell line you add should look similar to the following: 
neta = b,c,LM10,sessions, commands, names 


Replace the variables in the line with values shown in the following table: 


Table 14 Parameters for defining dual NetBIOS in IBMLAN.INI 








Variable Meaning of variable 
NET NET is a standard key word for NETWKSTA.200. It is not case-sensitive. 
a Replace a with a number from 1 to 4. This is the number of the network you want 


NETBIOS.OS2 to use when sending NetBIOS requests to a NETBIOS driver. Each 
NetBIOS driver must have its own network number. 


When specifying a network number: 
+ Use 1 for the Novell NetBIOS driver and 2 for the IBM NetBIOS driver. 


+ Do not use the same number that is used in any other net statements. Each network 
number can only be defined to one NetBIOS driver. 


+ Do not skip numbers. For example, if you have an existing net statement that uses 
NET1, use NET2 for your next statement. 





b Replace b with the device name for the NetBIOS driver. NETWKSTA.200 recognizes 
this name when determining which driver to pass NetBIOS calls to. 


Replace b with IPXNB$ for the Novell NetBIOS driver. 
(NETBEUIS$ is the device name for the IBM NetBIOS driver.) 
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Variable 





Meaning of variable 





LM10 


LM10 is the name of the protocol that enables NETWKSTA.200 to communicate with 
more than one NetBIOS driver. Type it exactly as it appears. 





Replace c with a number from 1 to 4. This number is the virtual adapter number used 
by the target NetBIOS driver to receive NetBIOS requests from NETWKSTA.200. 


+ For Novell's NetBIOS driver, always specify 1. 


+ For IBM's NetBIOS driver, specify whichever virtual adapter you want used. See the 
Extended Services documentation on NETBEUI.OS2 for more information on how 
it uses virtual adapters. 





sessions 


Replace sessions with the number of NetBIOS sessions you want allocated to the 
NetBIOS Submit application. This number specifies the maximum number of sessions 
that can be active between NETWKSTA.200 and Novell's NetBIOS driver. 


Novell's NetBIOS driver is configured with the sessions setting in the NET.CFG file. The 
number of sessions actually allocated to the application is either the NET.CFG value or 
the value on this line of the IBMLAN.INI, whichever is lowest. 


For example, if you set 64 sessions in NET.CFG, and the value on this line is only 48, 
the application will only be able to use 48 sessions. 


If you set 30 sessions in NET.CFG and the value on this line is 50, the application will 
only be able to use 30 sessions. 





commands 


Replace commands with the number of NetBIOS commands you want allocated to the 
NetBIOS Submit application. This number specifies the maximum number of 
commands that can be active between NETWKSTA.200 and Novell's NetBIOS driver. 


Novell's NetBIOS driver is configured with the names setting in the NET.CFG file. The 
number of names actually allocated to the application is either the NET.CFG value or 
the value on this line of the IBMLAN.INI, whichever is lowest. 


For example, if you set 128 commands in NET.CFG, and the value on this line is only 
100, the application will only be able to use 100 commands. 


If you set 80 commands in NET.CFG and the value on this line is 95, the application will 
only be able to use 80 commands. 
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Variable Meaning of variable 





names Replace names with the number of NetBIOS names you want allocated to the NetBIOS 
Submit application. This number specifies the maximum number of names that can be 
active between NETWKSTA.200 and Novell's NetBIOS driver. 


Novell's NetBIOS driver is configured with the names setting in the NET.CFG file. The 
number of names actually allocated to the application is either the NET.CFG value or 
the value on this line of the IBMLAN.INI, whichever is lowest. 


For example, if you set 128 names in NET.CFG, and the value on this line is only 100, 
the application will only be able to use 100 names. 


If you set 80 names in NET.CFG and the value on this line is 95, the application will only 
be able to use 80 names. 


For example, to enable applications to use both the Novell or the IBM 
NetBIOS driver, the lines in your IBMLAN.INI file might read: 


[networks] 
netl = IPXNBS,1,LM10,32,16,8 
net2 = NETBEUIS,1,LM10,16,16,8 


For more information about defining networks for NETWKSTA.200, see 
your LAN Services documentation. 


5 If your computer is a LAN Server, do the following: 

5a Find the [server] line in your I]BMLAN.INI file. 

5b At the end of the [server] section, find the following line: 
srvnets = neta 

5c Add the Novell NetBIOS network to the line. 
Separate the Novell net from any existing nets with a comma. 
For example, if Novell's NetBIOS driver was net2: 
srvnets = NET1,NET2 


The line must be indented at least one space and must follow other 
formatting requirements for IBMLAN.INI. 


This line tells LAN Services what network to send NetBIOS calls for 
servers on. 


6 If your computer is a LAN Requester, do the following: 
6a Find the [requester] line in your IBMLAN.INI file. 
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6b At the end of the [requester] section, find the following line: 
wrknets = neta 

6c Add the Novell NetBIOS network to the line. 
Separate the Novell net from any existing nets with a comma. 
For example: 
wrknets = NET1,NET2 


The line must be indented at least one space and must follow other 
formatting requirements for IBMLAN.INI. 


This line tells LAN Services what network to send NetBIOS calls for 
workstations on. 


7 Save the IBMLAN.INI file and exit your text editor. 


8 Use the "Shutdown" feature from the OS/2 system menu to reboot your 
computer. 


When your computer restarts, your NetBIOS Submit applications will be 
able to use both the Novell and the IBM NetBIOS driver. 


NOTE: NETWKSTA.200 must be started before any kind of NetBIOS connection 
will work. You can start it automatically on booting or with the LAN Services 
NETSTART command at a command line. See your LAN Services documentation 
for more information. 


Setting Up NetBIOS for DOS and Windows 


This section applies to virtual DOS and Windows sessions under OS/2 only. 
See the NetWare Workstation for DOS and Windows documentation to set up 
NetBIOS on an actual DOS or Windows workstation. 


NetWare Requester and the IBM LAPS program both support the NetBIOS 
protocol in a virtual session. However, the type of support is different. 


NetWare NetBIOS Support 


NetWare NetBIOS support is not virtualized. This means that the session will 
not use the same NetBIOS driver that is used by OS/2 sessions. 


Instead, you must load the NETBIOS.EXE TSR program in the session, just 
as you would to get NetBIOS support on an actual DOS workstation. 
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When you use the NETBIOS.EXE program in a virtual session, you will not 
be able to get NetBIOS connections from your OS/2 sessions or any other 
DOS and Windows sessions until the NETBIOS.EXE program is unloaded. 
You will only have one NetBIOS connection from a single virtual session. 
This is true even if your OS/2 NetBIOS drivers appears to be loaded. 


IBM LAPS NetBIOS Support 


The LAPS NetBIOS support is virtualized, meaning that you do not have the 
single-connection limitation. You do not have access to this virtualized 
support unless you have the LAPS protocols, included with both Extended 
Services and LAN Services from IBM. 


To use... Goto... 





NetWare Requester non- “Using NetWare NetBIOS Support for a Single 
virtualized NetBIOS support DOS Session” on page 146 





LAPS virtualized NetBIOS “Using LAPS NetBIOS Support for Virtual 
support Sessions” on page 148 


Using NetWare NetBIOS Support for a Single DOS Session 


As Figure 43 on page 147 shows, NetWare NetBIOS support for a single DOS 
session goes through NETBIOS.EXE and VIPX. 


IMPORTANT: When using NetWare NetBIOS for a single DOS session, you 
cannot have NetBIOS connections from any other DOS, Windows, or OS/2 
sessions. You must disable NetBIOS support for OS/2 sessions. 
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Figure 43 Novell NetBIOS Support for a virtual session 
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Prerequisites 


Q) Enable IPX support for virtual sessions. “Network Access from Virtual 
DOS and Windows” on page 19 explains how to do this. 


Q) Disable NetBIOS support for OS/2 sessions. Novell's NetBIOS solution 
for DOS boxes is not virtual and so does not allow any other NetBIOS 
drivers to be running at the same time. Disable NetBIOS support by 
running the NetWare Requester installation program and deselecting 
"NetBIOS Emulation for OS/2." “Installing the Driver” on page 131 
explains how to run the installation program. 


Procedures 


Follow the instructions in the NetWare Workstation for DOS and Windows 
manual. Use that documentation to 


+ Load NETBIOS.EXE in a single DOS session. 
+ Configure NetWare NetBIOS for DOS if necessary. 
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Using LAPS NetBIOS Support for Virtual Sessions 


As Figure 44 shows, LAPS virtual NETBIOS support goes through LANVDD 
and LANPDD. It uses the NETBIOS.OS2 interface to communicate with 
either the Novell or IBM NetBIOS driver. 


Figure 44 LAPS NetBIOS Support for Virtual Sessions 
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LAPS NetBIOS support follows the NetBIOS 3.0 (NB30) standard. You can 
run NetBIOS applications in a virtual session even if those applications are not 
NB30 conformant. However, the need for increasing resources in a session is 
more likely when running non-NB30 applications. 


Avoiding Resource Errors 


As you can see in Figure 44, your virtualized NetBIOS sessions can be 
supported by Novell's OS/2 NETBIOS.SYS driver or Extended Services's OS/ 
2 NETBEUI.OS82 driver or both. 


When virtual sessions are supported by Novell's OS/2 NetBIOS driver, you 
must be aware of a potential resource limitation. 


NOTE: If you have previously followed the steps in the “Configuring 
NETBIOS.OS2 with PROTOCOL.INI” on page 136, then you are using Novell's 


driver. 
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LAPS NetBIOS support for virtual sessions follows the NetBIOS 3.0 (NB30) 
standard. Among other things, a NetBIOS 3.0 application reserves a certain 
number of names, commands, and sessions when it first executes. 


If you run NetBIOS applications in several virtual sessions, you may find that 
all of the resources in one of the NetBIOS components get reserved and 
additional applications will not run. You will see a resource error when you try 
and make NetBIOS connections. 


You can minimize the possibility that NetBIOS will run out of resources by 


doing both or either of the following: 


+ Whenever you're using virtual NetBIOS connections, increase the default 
resources allowed for the NETBIOS driver in NET.CFG. 


“Configuring the Driver” on page 132 explains how to increase the 
defaults for the OS/2 NetBIOS driver. 


¢ Explicitly specify the resources consumed for each virtual session you 
use. 


“Procedures” on page 149 explains how to explicitly specify resources. 


Prerequisites 


0 Install Extended Services with NetBIOS support. See the Extended 
Services documentation. 


Q) Install LAN Services if you have it. See the LAN Services 
documentation. 


Q) Install the NetWare Requester with NetBIOS support. “Setting Up the 
Novell NetBIOS Driver” on page 130 explains how to do this. 


QO) Configure NETBIOS.OS2 to use both the Novell and IBM drivers. 
“Configuring NETBIOS.OS2 with PROTOCOL.INI” on page 136 
explains how to do this. 





Procedures 


These instructions explain how to set resource information for Extended 
Services virtualized NetBIOS. This information is stored with a program 
called LTSVCFG.COM. 


The LTSVCFG.COM program is included with LAPS in Extended Services 
and LAN Services. 


4. Open the virtual session. 
2 Execute the LTSVCFG.COM program with the command line parameters 


you need. 
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For example, you might type the following to set the number of NetBIOS 
commands to 12: 


LTSVCFG.COM C=12 
Three parameters that apply to NetBIOS resources are: 


s=number of NetBIOS sessions 
n=names 
c=commands 


For more information about these and other NetBIOS parameters, see the 
LAPS documentation on NetBIOS. 


IMPORTANT: You cannot set the parameters for LTSVCFG.COM to amounts 
higher than the amounts currently set for the NETBIOS.OS2 or NETBIOS.SYS 
driver. The default sessions, names, and commands settings for the 
NETBIOS.SYS driver are: 


Sessions=16 
Names=24 
Commands=32 


You may have changed these defaults in your NET.CFG file. 
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Backing Up Your OS/2 Workstation 


Topic 





“Starting the TSA_OS2 Manually” on page 152 
“Starting the TSA_OS2 Automatically” on page 153 


“Setting Up Your TSA_OS2.CFG File” on page 154 





The system administrator or backup administrator can back up your OS/2 
workstation to the network. To allow access, run the NetWare TSA_OS2 
(Target Service Agent) program on your workstation. 


The TSA_OS2 program runs as an application in an OS/2 session. You can 
continue working in other sessions while TSA_OS2 is running on your 
workstation. Whenever the TSA_OS2 is running, SBACKUP or another 
backup program can access the hard drive data. 


The TSA_OS2 is installed automatically on the hard drive when you install the 
NetWare Requester for OS/2. An icon for the TSA_OS2 is placed in the 
Novell group on your desktop. 


With the TSA_OS2 program, you can specify: 
+ Users on the network who can access your hard drive 


+ Password they must type in the backup program before accessing your 
hard drive 


¢ Drives on the hard drive that can be backed up 


Chapter 8, "Backing Up and Restoring Data," in Supervising the Network 
explains more about backing up workstations and servers. 
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Starting the TSA_OS2 Manually 


This section explains how to start TSA_OS2 manually by choosing its icon on 
your desktop. “Starting the TSA_OS2 Automatically” on page 153 explains 
how to start the TSA_OS2 automatically each time you boot your workstation. 


Prerequisites 
QO) Load the TSA_OS2.NLM on the server. 





Q) Install the NetWare Requester. See Chapter 3, "Installing a NetWare 
Workstation" in Workstation Basics and Installation. 


Procedures 
41 Choose the "Novell" icon on your OS/2 desktop. 
The "Novell" window appears. 


2 From the "Novell" window on your desktop, choose the icon for the 
TSA_OS2.EXE program. 


The TSA_OS2 main window appears. See Figure 45 on page 153. 
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Figure 45 The TSA_OS2 main window 
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3 Choose the features you want from the menu bar. 


Choose "Help" or press <F1> for more information. 


Starting the TSA_OS2 Automatically 
You can set up the TSA_OS2 program to start up automatically each time you 
boot your machine. To do this, you need to 
+ Place your TSA_OS2 icon in the "Startup" folder. 
This section explains how to put the icon in the "Startup" folder. 
+ Set up your TSA_OS2.CFG file. 


“Setting Up Your TSA_OS2.CFG File” on page 154 explains how to use 
a TSA_OS2.CFG file. 
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Prerequisites 
QO) Load the TSA_OS2.NLM on the server. 





Q) Install the NetWare Requester. See Chapter 3, "Installing a NetWare 
Workstation," in Workstation Basics and Installation. 


Procedures 
4 Open the "OS/2 System" folder on your desktop. 
The "OS/2 System" window appears. 
2 Open the "Startup" folder from the "OS/2 System" window. 
The "Startup" window appears. 


3 Without closing the "Startup" window, open the "Novell" group on your 
desktop. 


The "Novell" window appears. 


4 Drag the TSA_OS2.EXE icon from the "Novell" window into the 
"Startup" folder. 


Whenever you reboot your machine, the TSA_OS2 program will start 
automatically. If you have a TSA_OS2.CFG file set up, that file will be 
read each time the TSA_OS2 program starts. 


IMPORTANT: If backups at your site are normally done after hours, remember to 
leave the OS/2 workstations turned on or the backup administrator will not be able 
to access the hard drive. 


Setting Up Your TSA_OS2.CFG File 


You can create a text file called TSA_OS2.CFG to store settings for the 
TSA_OS2 program. These settings are automatically read by the TSA_OS2 
program each time the program starts up. Table 15 on page 155 lists the 
parameters you can type in the configuration file. 
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Table 15 List of TSA_OS2.CFG parameters 





Parameter Description Example 





WSName The Target Service name you assign to your WSName JO_OS2 
workstation. Do not use spaces in the 
workstation name. 





ServerName The name of the server where the Target ServerName SALES MKTG 
Service Agent Router NLM is loaded. 





UserName The User objects you allow to attach to the UserName NANCY 
OS/2 workstation. Repeat this line for each 
User object. If you want to specify a or to set a password of NEATO: 


password, simply specify it on the same line 


UserName NANCY NEATO 
as the username. 


The username must be one that is defined on 
the network. The password is unique to your 
workstation, not the same password the user 
types to access the network. If you specify a 
password, the backup administrator will have 
to type that password in the backup program. 








HideResource The drives you do not want to be backed up. ~HideResource C 
Repeat this line for each drive. The colon , 
after the driver letter is allowed, but not HideResource D: 
required. 

AutoRegister Automatically register with the Target Service AutoRegister ON 


Router NLM on the server whenever your 
workstation boots. To use this parameter, you °° 

must also specify a valid WSName, : 
ServerName, and UserName. RupRadisle Ore 





TempFilesDir The location on your hard drive where the TempFilesDir C:\TEMP_TSA 
backup program can temporarily store files 
during backup. These files are removed 
when backup is completed. Do not use 
spaces in the directory name. 


If you do not specify this parameter, the 
temporary directory will be located in the root 
of the directory where you started the 
TSA_OS2.EXE program from. 
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The following is a sample TSA_OS2.CFG configuration file: 


WSName Joe's Machine 
ServerName SALES MKTG 
UserName FredJ 
UserName Mark 

UserName admin 
UserName lisa NEATO 
HideResource c: 
hideresource b: 
AUTOREGISTER on 
tempfilesdir c:\emp os2 


The file is not case-sensitive. 
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Remote-Booting OS/2 Workstations 


Topic 





“Setting Up a Server to Boot Workstations Remotely” on page 157 
“Installing OS/2 Files for Remote Workstations” on page 159 
“Installing RIPL Files for Remote Workstations” on page 162 
“Adding Remote Workstations to the Network” on page 166 


“Configuring the Requester for Remote Workstations” on page 172 


OS/2 workstations that boot from the network do not need a workstation hard 
disk. Instead, they can run OS/2 and the Requester from network hard disks. 


Remote-booting workstations must have network boards with remote boot 
PROMs attached. Boot PROMs allow workstations to connect to the network 
so that the boot information can be accessed. 


Setting Up a Server to Boot Workstations Remotely 


Creating Users and Granting Access 


You have to set up accounts for Remote boot users. Do the following: 


Procedures 
4 Create the RPL User object. 


RPL is the username each remote workstation uses to make the initial 
connection to the network. 
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IMPORTANT: Do not require a password for the RPL User object, or the remote 
workstations will not be able to make the connection. Protect the account by 
granting limited access, as explained in Step 3. 


2 Create a User object for each user who will use a remote workstation. 
3 Grant access to the RPL User. 

The RPL user needs at least Read and File Scan access to 

+ The SYS:RPL2 directory 

+ The SYS:RPL2\COMPUTER directory and all its subdirectories 


These directories are created automatically during remote workstation 
installation. 


4 Grant access to each remote workstation user. 
All remote users need access to 
¢ The SYS:RPL2 directory 
+ The \OS2 and \NETWARE subdirectories under SYS:RPL2 
¢ Their home directories under SYS:RPL2\USER 


These directories are created automatically during remote workstation 
installation. 


Users should not have access to 
+ Other users’ home directories under SYS:RPL2\USER 
+ The SYS: volume 


WARNING: Since the SYS:RPL2 directory becomes the root of the C: drive for all 
remote users, all remote users require access to this area. You should not store 
critical files in this directory. Instead, store them in another network directory where 
access can be more restricted. 


You may want to warn users about this lack of privacy and encourage them to store 
data in their home directories (for example, C:\USER\MARY) or in another location 
on the network. 


To Boot Workstations with Novell Boards 


You can remote boot OS/2 workstations that have any of the following Novell 
boards: 


+ NE1000 
+ NE2000 
+ NE2 


158 NetWare Workstation for OS/2 v2.01 


To remote boot OS/2 workstations with these boards, you do not need to load 
any RPL loadable modules (NLMs) on the server. 


Follow the instructions in the rest of this chapter. 


To Boot Workstations with IBM Boards 


You can remote boot workstations that have either of the following IBM 
boards: 


+ PCN2L 
+ TOKEN 


To set up the server to remote boot this type of workstation, you must load and 
bind the RPL loadable module on each server by doing the following: 


Procedures 
4 At the server console, type 
LOAD RPL 
2 Then type 
BIND RPL TO driver 


Replace driver with the name of an LAN driver in your server. You can 
bind to more than one driver by specifying additional bind statements. 


For more information about the RPL loadable module, see the Utilities 
Reference manual. 


Installing OS/2 Files for Remote Workstations 


Complete the steps in this section if you are: 
¢ Setting up remote workstations for the first time. 
+ Upgrading existing remote workstations from OS/2 v1.3 to OS/2 v2.0. 


+ Adding a server to the network where remote workstations attach (only 
for the server you add). 


IMPORTANT: Don't do the steps in this section every time you want to add a 
remote workstation to the network. To add a remote workstation, see “Adding 
Remote Workstations to the Network” on page 166. 
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Prerequisites 


For the Workstation You're Installing From 


CL) Make sure OS/2 is installed on the workstation C: drive. It must be drive 
C: 


Q) Install the NetWare Requester in the \NETWARE directory 
QO) Make sure the workstation connected to a server when it booted. 


QO) Move to backup diskettes or delete all personal files in the C: drive. (The 
installation program copies all files from the C: drive to the server.) 


Q Make sure the CONFIG.SYS file only loads programs that remote 
workstations will need. 





QO) Obtain an OS/2 installation diskette if you are setting up PS/2 computers 
as remote workstations. If you are using PS/2 computers as remote 
workstations, the program must copy some files from this diskette. 


For the NetWare Servers Where You're Installing Remote Boot Support 


Procedures 


QO) Make sure you have the Supervisor object right to the NetWare Server 
object. 





QO) Make sure enough disk space is free on each server where you want to 
install. You need to allow 30 MB for OS/2 plus enough space for 
whatever files are on the workstation hard drive you're installing from. 


U Do the steps in “Setting Up a Server to Boot Workstations Remotely” on 
page 157. 


IMPORTANT: All remote files must be installed on each server on the network. If 
you have servers where you don't want to install remote workstation support, you 
can set the following paramter and the servers will not respond to remote PROMs: 


SET RESPOND TO GET NEAREST SERVER = OFF 


You can type this command at the server console or put it in your server 
AUTOEXEC.NCF file. If you set this parameter, the server will not be able to boot 
remote workstations, but you will also not have to install the files for remote 
workstations support on that server. See Utilities Reference for more information 
about the SET command. 
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We recommend that you establish a separate physical network for remote OS/ 
2 users. Put as few servers on this network as you need to support the number 
of remote users you have. If you want, connect this network to other networks 
at your site through routers. This setup saves time and server space. 


4 Ona workstation with the NetWare Requester installed, open the 
NetWare Requester for OS/2 installation program. 


Figure 46 shows how to open the program. 


Figure 46 Opening the installation program from the Novell group 
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The "NetWare Requester for OS/2 Installation Utility" window appears. 
Use the online help as necessary. 


2 Choose "Remote workstations. . ." from the "Installation" menu. 
The "Install Requester for Remote Workstations" window appears. 
3 Select "Only Copy OS/2 Files..." and choose "OK" 


You can choose other actions from the "Remote Workstation Installation" 
screen if you want. 


4 Choose the server(s) you want the files copied to. 


You will be attached to the server or servers you select. It must be 
installed on all servers on local net (cable segment with same address). 
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5 Choose "OK." 
All OS/2 and NetWare Requester files are copied to the servers. 
6 After the files are copied, do the following. 











If you want to... Do this... 

Copy remote boot files Without exiting the installation program, go to 
“Installing RIPL Files for Remote Workstations” 
on page 162. 

Add remote workstations to Without exiting the installation program, go to 

the network “Adding Remote Workstations to the Network” on 
page 166. 





Configure the Requester for Without exiting the installation program, go to 
remote workstations “Configuring the Requester for Remote 
Workstations” on page 172. 





Exit the installation program Choose "Close" from the system menu in the 
upper left corner of the Installation window. 





What Happens When You Install OS/2 Files 


+ A SYS:RPL2 directory is created on each server you selected. 


All remote workstations use this directory as if it is their local root drive. 
Once remote users log in to the network, they can access all information 
in this directory. 


Since the SYS:RPL2 directory is actually on the server and not on a local 
disk, NetWare security still applies. For example, you can limit remote 
users' access to specific directories and files. “Setting Up a Server to Boot 
Workstations Remotely” on page 157 explains more about securing the 
SYS:RPL2 directory and its subdirectories. 


NOTE: OS/2 v1.3 remote workstations used a directory called SYS:RPL. This 
directory is not erased when the SYS:RPL2 directory is created. OS/2 v1.3 remote 
workstations and OS/2 v2.01 workstations can both boot on the same network. 


¢ Every file from the workstation drive C: is copied to the SYS:RPL2 
directory on the server. 


162 NetWare Workstation for OS/2 v2.01 


Installing RIPL Files for Remote Workstations 


Complete the steps in this section if you are: 
¢ Setting up remote workstations for the first time. 
+ Upgrading existing remote workstations from OS/2 v1.3 to OS/2 v2.0. 


+ Adding a server to the network where remote workstations attach (only 
for the server you add). 


Don't do the steps in this section every time you want to add a remote 
workstation to the network. To add a remote workstation, see “Adding Remote 
Workstations to the Network” on page 166. 


Prerequisites 


For the Workstation You're Installing From 
Q Make sure the NetWare Requester is installed. 


LL) Make sure the workstation connected to a server when it booted. 


For the NetWare servers where you're installing remote boot support 


QO) Make sure you have the Supervisor object right to the NetWare server 
object. 


U Do the steps in “Setting Up a Server to Boot Workstations Remotely” on 
page 157. 





ü Do the steps in “Installing OS/2 Files for Remote Workstations” on page 
139. 


Procedures 


IMPORTANT: All remote files must be installed on each server on the network. 
There is no way to specify which server a remote workstation will initially establish 
a connection with. 


We recommend that you establish a separate physical network for remote OS/ 
2 users. Put as few servers on this network as you need to support the number 
ofremote users you have. If you want, connect this network to other networks 
at your site through routers. This setup saves time and server space. 
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1 Ona workstation with the NetWare Requester installed, open the 
NetWare Requester for OS/2 installation program. 


Figure 47 shows how to open the program. 


Figure 47 Opening the installation program from the Novell group 
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The "NetWare Requester for OS/2 Installation Utility" window appears. 
Use the online help as necessary. 


2 Choose "Remote workstations. . ." from the "Installation" menu. 
The "Install Requester for Remote Workstations" window appears. 
3 Choose "Only Copy RIPL Files..." 


' 


You can choose other actions from the "Remote Workstation Installation' 
screen if you want. 


4 Choose the server(s) you want the RIPL files copied to. 


You will be attached to the server or servers you select. It must be 
installed on all servers on local net (cable segment with same address) 


5 Choose "OK." 


All remote boot files are copied to the servers. 


164 NetWare Workstation for OS/2 v2.01 


6 After the files are copied, do the following. 


If you want to... Do this... 





Add remote workstations to Without exiting the installation program, go to 
the network “Adding Remote Workstations to the Network” 
on page 166. 





Configure the Requester for Without exiting the installation program, go to 
remote workstations “Configuring the Requester for Remote 
Workstations” on page 172. 





Exit the installation program Choose "Close" from the system menu in the 
upper left corner of the Installation window. 


What Happens When You Install RIPL Files 


When you use the installation program to install remote workstation support, 
the following actions occur. 


Directories Are Created 
+ SYSRPL2 is created if it didn't already exist 


+ The \USER and \COMPUTER subdirectories are created under 
SYS:RPL2 on each server. 


For an illustration of the complete directory structure created when you install 
remote workstation support and add remote workstations, see Figure 50 on 
page 172. 


Files Are Copied 


The following remote boot image files are copied to the SYS: LOGIN 
directory: 


+ TOKEN.200 
+ NE2.200 

NE2000.200 
NE1000.200 
PCN2L.200 


+ 


+ 


+ 
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These remote boot image files have different names than the remote boot 
image files used to boot OS/2 v1.3. OS/2 v1.3 remote boot files are also 
located in the SYS:LOGIN directory. 


The following files are copied to the SYS:RPL2 directory: 
¢ MINLIFS 
+ MICRO.IFS 


Adding Remote Workstations to the Network 


Each workstation you will boot from the network must be added to the remote 
boot setup on the network. You identify to each server the user who will use 
that workstation, the node address, and the network board. 


Workstations are added by running the Requester installation program from a 
workstation that has a hard disk. 


Complete the steps in this section on each server if you are: 
¢ Setting up remote workstations for the first time 
+ Upgrading existing remote workstations from OS/2 v1.3 to OS/2 v2.0 
+ Adding remote workstations to the network 


+ Adding a server to the network (complete the steps on this server for 
every remote workstation currently defined on the other servers) 


Prerequisites 


For the Workstation You're Installing From 


Q Make sure the NetWare Requester is installed. 





CL) Make sure the workstation connected to a server when it booted. 


For Workstations You're Booting Remotely 


Q Make sure each workstation that will boot remotely has one of the 
following types of network boards installed: NE2, NE2000, NE1000, or 
any IBM-compatible PCN2L or Token-Ring board. 


QO) Make sure the matching remote boot PROMs are installed on each 
network board. 
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QO) Make sure the workstation is properly cabled to the network. 


Q) Make sure you know the network and node address of the workstation 
you're booting remotely. 


Procedures 


Whenever possible, use the same type of network board in all remote 
workstations. This will save you time when installing and make configuring 
remote workstations much easier. 


If the installation program is already running, go to Step 4. 
4 Start up an OS/2 workstation that has the Requester installed. 
2 Open the "Novell" group icon on the desktop. 


3 Choose the Install icon in the "Novell-Contents" window. 


Figure 48 Opening the Installation program from the "Novell" group 


[$ Double-click here. J Then here. ] 










Novell 


Remote Printer NetWare Tools NetWare for 0512 


CJ 


NetWare Monitor 


Install 








The "NetWare Requester for OS/2 Installation Utility" window appears. 
4 Choose "Remote workstations. . ." from the "Installation" menu. 


The "Add Remote Workstations" menu appears. 
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5 Choose "Add remote workstations . . ." 

6 Choose servers on which you want to define remote workstations. 
For more information, use the online help. 

7 Add the workstations you want. 


Remote users are easier to manage if you assign only one remote 
workstation to a username. If you do let one user log in to more than one 
workstation, you can use the "Logical Name" option to set up each 
workstation's configuration differently. 


Choose "Help" or press <F1> for more information. 


8 Exit the installation program. 


To Remote Boot Workstations With Hard Disks 


If you want to remote boot a workstation with a hard disk, label your hard 
drive a drive other than C:. Drive C: must be assigned to the SYS:RPL2 
network directory. OS/2 thinks this network directory is the local C: drive. 


Also, you may need to do the following: 


+ If your hard disk is set to bootable or system (usually because you have a 
version of DOS installed on it), you need to run RPLON to keep your hard 
disk from booting. See “To Run RPLON” on page 168. 


+ Whether your hard disk has an operating system or not, you can format it 
(FAT) and use it to store your OS/2 SWAPPER.DAT file. This will cut 
down on network traffic. See “To Locate SWAPPER.DAT Locally” on 
page 169. 

To Run RPLON 


1 Insert the WSOS2_1/ diskette into a floppy drive of the workstation you 
want to boot remotely. 


2 Change to the drive you put the diskette into. 
For example, for a diskette in drive A:, type: 
CD A: 

3 Type: 

\RPL\RPLON <Enter> 
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The RPLON program keeps the hard disk at the workstation from 
booting. 


To enable the hard disk again, insert the WSOS2_/ diskette in the drive, 
change to that drive, and type \RPL\RPLOFF. 
To Locate SWAPPER.DAT Locally 


1 Go to the home directory on the network for the user who will be using 
the remote workstation. 


For example, if JOHN will be using the remote workstation with a hard 
drive, go to the following directory: 


SYS :RPL2\USER\JOHN 


Each user's home directory on the network contains that users 
CONFIG.SYS file and several other OS/2 files. Figure 50 on page 172 
shows the complete network directory structure for remote workstations. 


2 Ina text editor, open the CONFIG.SYS file. 

3 In the CONFIG.SYS file, find the line that designates the SWAPPATH. 
You can search for SWAPPATH. The line looks like the following: 
SWAPPATH=C: \OS2\SYSTEM 2048 2048 
Remember that to OS/2, the SYS:RPL2 directory is drive C:. 

4 Change the SWAPPATH line to point to the local hard drive. 

For example, to point to the root of a local drive D: 
SWAPPATH=D:\ 2048 2048 
5 Save and exit the CONFIG.SYS file. 


When you boot the remote workstation, the SWAPPER.DAT will be 
stored locally. 


What Happens When You Add Remote Workstations 


When you add remote workstations to a network, the following actions occur. 


Directories Are Created 


If you have not yet installed remote workstation support on the network, the 
SYS:RPL2 and the \USER and \COMPUTER directories are created on each 
server. 


Remote-Booting OS/2 Workstations 169 


The following directories are created for each workstation you add: 
+ A user's home directory under the \USER directory. 


This directory has the same name as the username you specify. For 
example, a user named JADAMS would have a home directory of: 


SYS: RPL2\USER\JADAMS 
+ A user's node address directory under the \COMPUTER directory. 


This directory has the same name as the last 11 characters of the 
workstation node address. For example, if the node address was 
222334S5BBBBB, the node address directory would be: 


SYS: RPL2\COMPUTER\223345BB.BBB 


+ A subdirectory containing the Workplace Shell desktop in each user's 
subdirectory. 


This directory is called OS!2_2.0 Dif you're installing from a FAT drive 
and "OS2 20 Desktop" if you're installing from an HPFS drive. 


+ A \SPOOL subdirectory in each user's subdirectory. 
This directory contains all desktop printing files. 


Files Are Created 


+ A file called CONFIG.WSS is created in each user's node address 
directory on the server. 


This file tells OS/2 to use the OS2.INI, OS2SYS.INI, and CONFIG.SYS 
files from the user's home directory on the network instead of trying to 
find these files in their regular locations on a local drive. 


It also tells OS/2 to use the desktop files and \SPOOL subdirectory from 
the user's home directory on the network rather than from a local hard 
disk. 


+ A BOOTCONE.SYS file is created in the SYS:LOGIN directory. 


If a BOOTCONE.SYS file already exists (from other installations of 
remote workstations), the information for the new workstations 1s added 
to the beginning of the file. 


This file tells the server which boot image file to use for each workstation. 
The BOOTCONE:SYS file contains lines identifying which remote 
workstation uses which type of network board. For example, a line for a 
Token-Ring workstation might be as follows: 


0xDOC20, 1b0276A32222=TOKEN. 200 
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See Figure 49 for an explanation of the lines in the BOOTCONE.SYS file. 


Figure 49 Format of BOOTCONF.SYS file 


The number zero The node address 
and the letter x are and an equal sign 


the first characters come next. 
on the line. 








0xDOC20,1B025322BB11=TOKEN.200 


The network The name of the 
address followed remote boot image 


by acomma file is last. 
comes next. 





Files Are Copied 


Every file in the \DESKTOP and \SPOOL subdirectories are copied from the 
local drive of the OS/2 workstation to the server. 


These files allow remote workstations to load customized versions of OS/2 
and the OS/2 desktop. 
CONFIG.SYS Is Copied and Modified 


A COMNFIG.SYS file is copied from the local drive of the OS/2 workstation 
you are installing from to each user's subdirectory on each server. 


This CONFIG.SYS is modified slightly for each user. The line which loads 
HPFS is commented out, and the directory in the SWAPPATH line is changed. 
Also, disk caching is turned off and the ODI driver is changed to the driver 
you selected. 


Figure 50 on page 172 shows the complete directory structure that is created 
for remote workstation support. 
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Figure 50 Directory structure for remote workstation support 
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Configuring the Requester for Remote Workstations 


OS2.INI files 


Configure the NetWare Requester for remote workstations by running the 
NetWare Requester installation program and choosing "Remote workstations 
..." from the "Configuration" menu. Chapter 4, “How to Configure Your 
Workstation,” on page 37 explains more about configuring from the 
installation program. 


When you configure remote workstations, the Requester installation program 
puts a NET.CFG configuration file in the home directory of the users you 
specify. The home directory is located under SYS:RPL2\USER on each server 
on the local network. 


172 NetWare Workstation for OS/2 v2.01 


The NET.CFG you create with the installation program should be identical on 
all servers on the local network so remote workstations boot the same way 
each time. 


For example, if user JOHN has a NET.CFG file in his user directory on 
SERVERI, then a copy of the same NET.CFG file should be placed in his 
home directory on SERVER2. 


The installation program puts a line in each user's CONFIG.WSS file in the 
workstation subdirectory, telling the Requester where to find the NET.CFG 
file. 


For example, for John's NET.CFG file, the installation program puts in the 
following line: 


C:\NET.CFG C:\USER\JOHN\NET. CFG 


NOTE: Remember that the SYS:RPL2 directory becomes the root of the C: drive. 
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System Messages 


Messages Summary 


This appendix includes system messages and explanations for all NetWare 
Requester v2.01 drivers and daemons. Messages for the NetWare Tools or the 
Network Printer (NPRINTER.EXE) programs are not included. For 
information about messages for those modules, see System Messages. 


REQO106: An error occurred during attempt to get shared memory. 


Explanation: 


Action: 


DDAEMON.EXE attempted to access the daemon's shared memory, but 
failed. At this point, the program has verified that the shared memory exists, 
but is unable to access it. This may be an internal program error. 


Try rebooting your system. If the problem persists, call your Novell 
Authorized Reseller. 


REQO0107: An error occurred during attempt to allocate a shared segment. 


Explanation: 


Action: 


DDAEMON.EXE tried to create shared memory, but none is available. This 
error usually occurs when the device drivers and applications currently 
running on your system require more memory than your system has available. 


Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 
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REQO0108: The daemon cannot access the Link Support Layer. Error: <code>. 


Explanation: 


Action: 


DDAEMON.EXE cannot find the Link Support device driver LSL.SYS. 


Make sure that the device driver LSL.SYS has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the LSL for any 
errors or warnings, and correct the problems indicated. Try again. If this error 
persists, call your Novell Authorized Reseller. 


REQ0109: The DDAEMON is already loaded. 


Explanation: 


Action: 


DDAEMON.EXE tried to create shared memory for the first time, but the 
memory already exists. Another daemon is already running. The attempt to 
create shared memory is terminated. 


Make sure that you are not trying to run multiple copies of the daemon. 
Typically the daemon is run from the CONFIG.SYS file at system startup and 
does not need to be executed again. 


REQ0204: The system does not have enough memory for socket tables. 


Explanation: 


Action: 


OS/2 lacks sufficient system memory for IPX to allocate memory for its 
socket tables. 


Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQO0205: The LAN support module could not be installed. 


Explanation: 


Action: 


Either the LSL.SYS driver failed to load, or the "DEVICE=" statement is 
missing from the CONFIG.SYS file. 


Either correct the problem that kept the LSL.SYS driver from loading 
(indicated in an error message preceding this one), or add the "DEVICE=" 
statement to the CONFIG.SYS file. 
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REQ0206: The IPX MLID could not be installed. 


Explanation: Either the Multiple Link Interface Driver (MLID) specified in the 
CONFIG.SYS failed to load, or the "DEVICE=" statement for an MLID is 
missing from the CONFIG.SYS file. 


Action: Either correct the problem that kept the MLID from loading (indicated in an 
error message preceding this one), or add the "DEVICE=" statement to the 
COMNFIG.SYS file. 


REQ0207: The configured LAN-A driver does not support IPX. 


Explanation: The Multiple Link Interface Driver (MLID) to which IPX.SYS attempted to 
bind does not support IPX-based data transmissions. 


Action: Bind IPX to an MLID that supports IPX-based data transmissions. 


REQ0208: The IPX protocol handler cannot be registered. 


Explanation: IPX cannot register with the LSL.SYS driver because the LSL is servicing its 
maximum number of protocol stacks. 


Action: Remove the "DEVICE=" statements for any unnecessary protocol stacks from 
the CONFIG.SYS file. 


REQ0209: The IPX entry point cannot be initialized. 


Explanation: The IPX and link support layer (LSL) versions may not be compatible 
versions. 


Action: Make sure that the IPX.SYS driver and LSL.SYS driver are compatible. If 
they are not, obtain compatible drivers from your Novell Authorized Reseller. 
If this is not the problem, contact your Novell Authorized Reseller for 
customer assistance. 


REQ0210: An internal error occurred. The IPX router socket cannot be opened. 
Explanation: IPX was unable to open the router socket due to an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0211: An internal error occurred. A router selector cannot be allocated. 


Explanation: IPX was unable to allocate an OS/2 router selector due to an internal program 
error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 
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REQ0212: The system has insufficient memory to allocate a router. 
Explanation: OS/2 cannot access sufficient system memory for IPX routing purposes. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0213: Router memory is exhausted. 
Explanation: IPX did not have enough memory previously allocated for routing purposes. 


Action: Increase the size of the IPX router memory in the NET.CFG "ROUTER 
MEM" statement. 


REQ0214: An internal error prevented CGroup variable initialization. 


Explanation: An internal program error has occurred. IPX was unable to initialize internal 
variables. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0215: An internal error prevented DosHIp variable initialization. 
Explanation: OS/2 internal variables were either incomplete or invalid. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0216: IPX cannot register with OS/2 for PDD-to-VDD communications. 


Explanation: This is an internal program error. IPX cannot register with OS/2 for 
VIPX.SYS driver support. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0217: The IPX device driver is not running. 


Explanation: Either IPX.SYS encountered a fatal error during system initialization, or the 
"DEVICE=[path]IPX.SYS" statement was missing from the CONFIG.SYS 
file. If the problem is a fatal error, another message should precede this one 
that identifies the specific error that occurred. 


178 NetWare Workstation for OS/2 v2.01 


Action: Either resolve the fatal problem (indicated in a preceding message), or add the 
"DEVICE=" statement to the CONFIG.SYS file; then try again. If the problem 
persists, contact your Novell Authorized Reseller. 


REQ0231: The default protocol configuration option is not used for IPX. 
Explanation: IPX cannot be configured as a default protocol stack. 


Action: Remove this option statement from the NET.CFG file. 


REQ0232: The prescan protocol configuration option is not used for IPX. 
Explanation: IPX cannot be configured as a prescan protocol stack. 


Action: Remove this option statement from the NET.CFG file. 


REQ0233: The OS/2 version number cannot be found; OS/2 v2.0 is assumed. 


Explanation: IPX's query of OS/2 for the version number returned a value that did not match 
the value it expected to receive. 


Action: | Make sure the OS/2 version installed on the machine is v2.0 or later. 


REQO0304: An LSL error occurred. NET.CFG buffers are too big for ECB pool. 


Explanation: The configured buffer size for the Link Support component is too large. Total 
available buffer space is around 60 KB, but the Link Support Layer (LSL) is 
unable to allocate even one buffer of the requested size in its buffer space. See 
"Link Support Layer" in Concepts for more information about LSL. 


Action: Reduce the Link Support component's buffer size in the NET.CFG file. It is 
more important to have several smaller buffers available than one large one. It 
is a waste of system memory to configure buffers much larger than the 
communications media can support. 


REQO0305: The Link Support module (LSL) could not install the AES timer. 


Explanation: The Link Support Layer (LSL) could not register its timer handler with the 
operating system because the maximum number of handlers have already 
been installed. This timer handler is a critical component of the Requester, and 
none of the Novell-supplied communication handlers can be expected to work 
properly without it. See "Link Support Layer" in Concepts for more 
information about LSL. 
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Action: Previously installed device drivers (those entered before LSL.SYS in the 
CONFIG.SYS file) have used all available timer resources. Identify those 
device drivers and either remove or reconfigure them. Since the Requestor's 
communications handlers all use a common timer service in the LSL, only one 
available timer handler is required for proper operation. If you are unable to 
resolve this problem, contact your Novell Authorized Reseller. 


REQ0306: The Link Support module could not initialize its call gate. 


Explanation: The Link Support module could not register its entry point with the operating 
system. This entry point is vital to most of the Requester's communications 
components, and its absence will cause them to fail. The most likely cause of 
this error is a previously loaded device driver that is using too many kernel 
resources. 


Action: Try removing application device drivers installed before LSL.SYS in the 
CONFIG.SYS file. It is highly unlikely that a device driver from the OS/2 
base system has caused this error. If the problem persists, contact your Novell 
Authorized Reseller. 


REQ0404: NetBIOS error occurred. Link Support module cannot be installed. 


Explanation: NetBIOS could not open or communicate with the Link Support LINKSUP__ 
device driver. This can happen if the Link Support Layer (LSL) driver has not 
been properly installed or if you are using the wrong version of the driver. See 
"Link Support Layer" in Concepts for more information about LSL. 


Action: Make sure that the device driver LSL.SYS has been properly entered in the 
CONFIG.SYS file. If so, check the messages displayed by the LSL for any 
errors or warnings, and correct the problems indicated. If the Link Support 
device driver is initializing properly, the problem is with incompatible 
versions of the software. NetBIOS and Link Support are usually installed 
together from a single installation diskette. Try reinstalling them. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0405: NetBIOS error occurred. The IPX module is not installed. 


Explanation: NetBIOS could not open or communicate with the Link Support LINKSUP__ 
device driver. This can happen if the Link Support Layer (LSL) driver has not 
been properly installed or if you are using the wrong version of the driver. See 
"Link Support Layer" in Concepts for more information about LSL. 


Action: Make sure that the device driver LSL.SYS has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the LSL for any 
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errors or warnings, and correct the problems indicated. If the Link Support 
device driver is initializing properly, the problem is with incompatible 
versions of the software. NetBIOS and Link Support are usually installed 
together from a single installation diskette. Try reinstalling them. If the 
problem persists, contact your Novell Authorized Reseller. 


REQO0406: The NetBIOS call gate cannot be initialized. 


Explanation: 


Action: 


This is an internal program error. 


Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0407: NetBIOS error occurred. The program cannot initialize local NCBs. 


Explanation: 


Action: 


Insufficient memory is available for the NCBs requested. Usually this error is 
caused by incorrect configuration information in the NET.CFG file. However, 
the underlying problem could also be a lack of global system resources in the 
OS/2 Global Descriptor Table. 


Reduce the number of commands in the NetBIOS section of the 
COMFIG.SYS file. (The default number of commands is 12; the maximum 
allowed is 25.) You also might be able to reduce the number of node names 
(possible range is 0-126). Additional possibilities include adding RAM, 
reducing your configuration options (for example, reducing the size of 
DIRCACHE) or removing optional device drivers from the CONFIG.SYS 
file, and freeing up some hard disk space by deleting unnecessary programs. 
If you are using multiple disk partitions, consider moving the OS/2 swapper 
file to a larger partition. Disk compression utilities may also be available that 
can help resolve this problem. After completing these actions, shut down OS/ 
2 and then reboot the system. If the problem persists, contact your Novell 
Authorized Reseller. 


REQ0408: NetBIOS emulator parameters are too large for the memory pool. 


Explanation: 


Action: 


Insufficient memory is available for all of the control tables needed by the 
NetBIOS emulator. 


The amount of table space available to the NetBIOS emulator cannot be 
increased. The only way to solve this problem is to reduce the number of 
NetBIOS resources you are requesting. You can do this by modifying the 
NETBIOS parameters in the NET.CFG file. If the problem persists, contact 
your Novell Authorized Reseller. 
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REQ0409: Incompatible versions of OS/2 and NetBIOS are running. 


Explanation: 


Action: 


You are attempting to run NetBIOS v2.01 on some version of OS/2 earlier than 
OS/2 v2.0. 


Either install OS/2 v2.0 to run with NetBIOS v2.01, or install a different 
version of NetWare NetBIOS to match your OS/2 version. 


REQ0504: The SPX module is not installed. 


Explanation: 


Action: 


The NMPIPE.SYS driver could not open or communicate with the SPX.SYS 
driver. 


Make sure that the SPX.SYS driver has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated; then try again. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0505: The IPX module is not installed. 


Explanation: 


Action: 


NMPIPE.SYS could not open or communicate with the IPX.SYS driver. 


Make sure that the IPX.SYS driver has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated; then try again. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0519: An incorrect OS/2 version is being used. 


Explanation: 


Action: 


Either the DosGetVersion call failed (an internal program error), or the OS/2 
version currently running is not v2.0 or later. 


Make sure the client OS and NMPIPE.SYS driver are compatible versions. If 
the problem persists, contact your Novell Authorized Reseller. 


REQ0520: The driver cannot register the PDD for VDD-to-PDD communications. 


Explanation: 


Action: 


NMPIPE.SYS could not register IPX as a PDD so that PDD to VDD 
communication may take place. 


Make sure the IPX.SYS driver has been properly entered in the CONFIG.SYS 
file. If so, check the messages displayed by the driver for any errors or 
warnings, and correct the problems indicated. Also make sure the OS/2 
version is v2.0 or later; then try again. If the problem persists, contact your 
Novell Authorized Reseller. 
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REQ0613: Invalid characters were specified in COMPUTERNAME. 
Explanation: The Named Pipes server name specified after NPDAEMON.EXE is invalid. 


Action: | Make sure the server name is not more than 15 characters and is composed of 
letters, numbers, and these special characters: !#$%&()-.@*_\Q {}~ 


REQ0614: An error occurred during attempt to initialize NPCALLS.DLL. 
Explanation: The NPDaemon could not initialize NPCALLS.DLL. 


Action: Make sure the NPCALLS.DLL file in the NetWare Requester directory is 
included in the LIBPATH statement of the CONFIG.SYS file. If you are 
running Named Pipes, make sure the NMPIPE.SYS driver and 
NPSERVER.SYS are correctly configured in the CONFIG.SYS file. 


REQ0615: The Named Pipes daemon could not be registered. Error: <code>. 


Explanation: The NPDaemon could not open or communicate with the NMPIPE.SYS 
driver. 


Action: Make sure the NMPIPE.SYS driver has been properly entered in the 
CONFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems. Try again. If the problem 
persists, contact your Novell Authorized Reseller. 


REQ0616: An error occurred during attempt to allocate shared memory. 
Explanation: The NPDaemon could not allocate shared memory. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0617: An error occurred during attempt to allocate the ECB pool. 
Explanation: The NPDaemon could not allocate memory for the ECB pool. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
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space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0618: An error occurred during attempt to create a system semaphore. 
Explanation: A DosCreateSem call failed. An internal program error may have occurred. 


Action: Try again. If the error persists, contact your Novell Authorized Reseller. 


REQ0619: An error occurred during attempt to create a thread. 
Explanation: A beginthread call failed. An internal program error may have occurred. 


Action: Try again. If the error persists, contact your Novell Authorized Reseller. 


REQ0620: A dynamic socket could not be opened. Error: <code>. 
Explanation: The NPDaemon failed to open a dynamic socket. 


Action: Increase the socket count specified in the NET.CFG file; then reboot the 
system and try again. If the problem persists, contact your Novell Authorized 
Reseller. 


REQ0621: A well-known socket could not be opened. Error: <code>. 


Explanation: The NPDaemon could not open Netware's registered Named Pipe socket; the 
socket may already be in use. 


Action: Increase the SPX socket count in the NET.CFG and shut down OS/2; then 
reboot the system. 


REQ0622: The NPDaemon cannot get the internet address. Error: <code>. 
Explanation: An IpxGetInternetworkAddress call failed. 


Action: Make sure the IPX.SYS driver has been properly entered in the CONFIG.SYS 
file. If so, check the messages displayed by the driver for any errors or 
warnings, and correct the problems indicated. Also make sure the 
IPXCALLS.DLL file is in the NetWare Requester directory; then try again. If 
the problem persists, notify your Novell Authorized Reseller. 
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REQ0623: The NPDaemon cannot get the local target. Error: <code>. 
Explanation: An IpxGetLocalTarget call failed. 


Action: Make sure the IPX.SYS driver has been properly entered in the CONFIG.SYS 
file. If so, check the messages displayed by the driver for any errors or 
warnings, and correct the problems indicated. Also make sure the 
IPXCALLS.DLL file is in the NetWare Requester directory; then try again. If 
the problem persists, contact your Novell Authorized Reseller. 


REQ0624: The service advertising function failed. Error: <code>. 
Explanation: An IpxSend call to advertise this workstation as Named Pipe Server failed. 


Action: Make sure the IPX.SYS driver has been properly entered in the CONFIG.SYS 
file. If so, check the messages displayed by the driver for any errors or 
warnings, and correct the problems indicated. Also make sure the 
IPXCALLS.DLL file is in the NetWare Requester directory; the try again. If 
the problem persists, contact your Novell Authorized Reseller. 


REQ0625: The broadcast socket cannot be opened. Error: <code>. 


Explanation: The broadcast socket cannot be opened. This is a registered socket by which 
SAPs can be received. Possibly this socket has already been opened. 


Action: Increase the socket count in the NET.CFG file and shut down OS/2 and then 
reboot the system. If the problem persists, contact your Novell Authorized 
Reseller. 


REQ0626: An error occurred during attempt to get code page information. 
Explanation: A call to DosGetCtryInfo failed. This may be an internal program error. 


Action: | Make sure the OS/2 is version 2.0 or later. If so, and the problem persists, 
contact your Novell Authorized Reseller. 


REQ0628: Memory cannot be allocated for turbo buffers. 
Explanation: The NPDaemon could not allocate memory for turbo buffers. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 


SystemMessages 185 


After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0629: A connection thread died abnormally. Error: <code>. 
Explanation: The connection controller thread died unexpectedly. 


Action: Make sure that the SPX.SYS driver has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated. Also make sure all of 
your Named Pipe drivers are within the same major version (for example, 
v2.x); then try again. If the problem persists, contact your Novell Authorized 
Reseller. 


REQ0630: The specified computer name is already registered on the internet. 


Explanation: The Named Pipes server name specified in the CONFIG.SYS file has already 
been used on the network. 


Action: Use a different server name. 


REQ0631: The receive buffer manager died abnormally. Error: <code>. 
Explanation: The receive buffer manager thread died unexpectedly. 


Action: Make sure that your Named Pipes drivers are within the same major version 
(for example, v2.x). If so, try adding RAM, reducing your configuration 
options in the CONFIG.SYS file (for example, reducing the size of 
DIRCACHE), removing optional device drivers from the CONFIG.SYS file, 
and freeing up some hard disk space by deleting unnecessary programs. If you 
are using multiple disk partitions, consider moving the OS/2 swapper file to a 
larger partition. Disk compression utilities may also be available that can help 
resolve this problem. After completing these actions, shut down OS/2; then 
reboot the system. If the problem persists, contact your Novell Authorized 
Reseller. 


REQ0632: An error occurred checking for nondedicated server. 


Explanation: The NPDaemon could not open or communicate with the NWREQ.SYS 
driver. 


Action: Make sure that the NWREQ.SYS driver has been properly entered in the 
CONFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated. Make sure 
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NWREQSSYS is version 2.0 or greater. Try again. If the problem persists, 
contact your Novell Authorized Reseller. 


REQO0633: An error occurred allocating memory for nondedicated SAP buffer. 


Explanation: 


Action: 


NPDaemon could not allocate memory. 


Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0634: The NPDaemon could not obtain a server list. 


Explanation: 


Action: 


The Named Pipes daemon failed in its attempt to obtain a list of servers from 
the NetWare for OS/2 server running on the same machine. 


Make sure you are running the latest version of the NetWare for OS/2 server. 
If the problem persists, contact your Novell Authorized Reseller. 


REQ0704: The SPX module is not installed. 


Explanation: 


Action: 


The Named Pipes daemon could not open or communicate with the SPX.SYS 
driver. 


Make sure that the SPX.SYS driver has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated; then try again. If the 
problem persists, contact your Novell Authorized Reseller. 


REQO0705: The IPX module is not installed. 


Explanation: 


Action: 


The Named Pipes daemon could not open or communicate with the IPX.SYS 
driver. 


Make sure that the IPX.SYS driver has been properly entered in the 
CONFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated; then try again. If the 
problem persists, contact your Novell Authorized Reseller. 
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REQ0719: An incorrect OS/2 version is being used. 


Explanation: The DosGetVersion call failed (which would indicate an internal program 
error) or the OS/2 version currently running is not v2.0 or later. 


Action: Make sure that the client OS and NMPIPE.SYS driver are compatible; then try 
again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0806: The program cannot get code page information. Error: <code>. 


Explanation: The OS/2 system is not returning code page information. This may be an 
internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0807: The Requester device driver and daemon are incompatible versions. 


Explanation: The most likely cause of this problem is that NWDAEMON.EXE and 
NWREQ.SYS driver were not installed from the same installation disk. 


Action: Install the Requester driver again, making sure it is from the correct 
installation disk. 


REQ0808: The worker DLL cannot be registered. Error: <code>. 


Explanation: The NWWORKER.DLL could not register with the Requester. This may be 
an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0809: The broadcast handler cannot be registered. Error: <code>. 
Explanation: This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0810: The program cannot get system information. Error: <code>. 


Explanation: The OS/2 system is not returning system information. This may be an internal 
program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0811: The janitor thread priority cannot be set. Error: <code>. 


Explanation: The janitor thread is set to run at regular priority. The system had trouble 
setting the priority. 


Action: Ignore the error. 
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REQ0812: The janitor daemon cannot be registered. Error: <code>. 
Explanation: This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0813: The program cannot get the current drive map. Error: <code>. 


Explanation: The OS/2 system is not returning the current drive map. This may be an 
internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0814: The program cannot set the current drive map. Error: <code>. 


Explanation: The OS/2 system is not setting the current drive map. This may be an internal 
program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0815: The program cannot get the connection ID. Error: <code>. 


Explanation: The Requester tried to locate a NetWare server when it initialized. Either no 
servers are currently running or a cabling problem exists. 


Action: Make sure the NetWare server is running and functioning properly. Also make 
sure the OS/2 machine has a working connection to the network; then try 
again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0816: An error occurred during attempt to initialize the cache. 
Explanation: The caching function is not working. This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0817: The daemon could not boost the thread priority. 


Explanation: The thread is set to run at a greater priority. The system had trouble setting the 
priority. 


Action: Ignore the error. 


REQ0818: The daemon could not register the DosBox handler. 
Explanation: This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 
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REQ0820: Not enough memory for diagnostic daemon. Error: <code>. 


Explanation: The NWDaemon program tried to allocate memory from the system for the 
diagnostic thread to use as a stack, but the system returned an error. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0821: The diagnostic daemon cannot be started. Error: <code>. 


Explanation: The NWDaemon tried to start the diagnostic thread but the system 
encountered an error condition. The system may have too many threads 
already running, or this may be an internal program error. 


Action: Try closing other applications that are currently running. If the problem 
persists, contact your Novell Authorized Reseller. 


REQ0822: The diagnostic daemon priority cannot be changed. Error: <code>. 


Explanation: The diagnostic thread is set to run at regular priority. The system had trouble 
setting the priority. 


Action: Ignore the error. 


REQ0823: Not enough memory to start a new thread. Error: <code>. 


Explanation: | The NWDaemon could not allocate memory from the system to create a thread 
for a new task. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 
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REQ0824: The SPX send thread cannot be started. Error: <code>. 
Explanation: This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0825: The SPX receive thread cannot be started. Error: <code>. 
Explanation: This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0826: The SFT 3 handler cannot be registered. 
Explanation: This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0827: Packet Burst cannot be initialized. 
Explanation: This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ0843: Not enough memory for a network management thread (<error code>). 


Explanation: The NWDaemon tried to allocate memory from the system for a thread to 
initialize network management, but memory was not available. Network 
management cannot be initialized. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0844: A named pipe cannot be started for network management (<error code>). 


Explanation: The NWDaemon could not allocate a named pipe. Network management will 
not be supported until the computer is rebooted. This error could result from 
a variety of causes. Named Pipes or SPX may not be loaded, one of your 
drivers may have opened too many Named Pipes already, you may not have 
enough memory or disk space, or it may be an internal program error. 
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Action: 


Make sure that Named Pipes and SPX are loaded and that your system has 
enough memory. (If you suspect a memory problem, see the discussion for 
message 843.) After completing these actions, reboot the system and try again. 
If the problem persists, contact your Novell Authorized Reseller. 


REQ0845: Not enough memory to run network management (<error code>). 


Explanation: 


Action: 


The NWDaemon program tried to allocate memory from the system to run 
network management, but memory is not available. Network Management 
will not run until memory is available and the system is rebooted. 


Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0904: The NWREQ.SYS driver is not loaded. 


Explanation: 


Action: 


The Requester cannot be initialized until the driver is loaded. 


Load the NWREQ.SYS driver. 


REQ0914: The program cannot allocate selectors for the workspace table. 


Explanation: 


Action: 


All available memory selectors are being used by the system or by previously 
loaded device drivers. 


Remove optional or unneeded device drivers from the CONFIG.SYS file and 
try again. If the problem persists, contact your Novell Authorized Reseller. 


REQO0915: The program cannot allocate memory for the workspace table. 


Explanation: 


Action: 


All available system memory is in use. The Requester cannot load properly. 


Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
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After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ0917: Memory is not available for the cache table. Caching is disabled. 


Explanation: 


Action: 


All available system memory is in use by the system. The Requester cannot 
load properly. 


Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQO0919: An incorrect OS/2 version is being used. 


Explanation: 


Action: 


The major versions of the Requester and OS/2 do not match. 


Upgrade the Requester or OS/2. 


REQ0937: The Requester driver version does not match the IFS version. 


Explanation: 


Action: 


NWIFS.IFS and NWREQ.SYS were not installed from the same installation 
disk. 


Install the Requester again. If the problem persists, contact your Novell 
Authorized Reseller. 


REQ1004: The LAN support module is not installed. 


Explanation: 


Action: 


The Requester driver requires the LSL.SYS driver to be running when it loads. 
Either the "DEVICE=C:\NETWARE\LSL.SYS" line is missing from the 
CONFIG.SYS file or the LSL encountered an error while loading. 


Check the CONFIG.SYS file for the LSL.SYS driver. If this is not the 
problem, contact your Novell Authorized Reseller. 


REQ1008: A NetWare server cannot be found. 


Explanation: 


Action: 


The Requester tries to locate a NetWare server when it initializes. Either no 
servers are currently running or there is a cabling problem. 


Make sure that the NetWare server is running and operating properly. Also 
make sure that the OS/2 machine is connected to the network. 
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REQ1010: The program cannot allocate selectors for the connection table. 


Explanation: All available memory selectors are being used by the system or by previously 
loaded device drivers. 


Action: Remove optional or unneeded device drivers from the CONFIG.SYS file and 
try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1011: The program cannot allocate memory for the connection table. 
Explanation: All available system memory is in use. The Requester cannot load properly. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system.If the 
problem persists, contact your Novell Authorized Reseller. 


REQ1019: An incorrect OS/2 version is being used. 
Explanation: The major version of the Requester and OS/2 do not match. 


Action: Upgrade the Requester or OS/2. 


REQ1021: The config file cannot be parsed. Default parameters will be used. 
Explanation: The Requester driver could not read parameters in the NET.CFG file. 


Action: Make sure the syntax for the NetWare Requester section of the file is correct. 


REQ1022: An unrecoverable error occurred. The driver was not loaded. 
Explanation: The driver could not load properly. This is probably an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1024: The program cannot allocate selectors for worker support. 


Explanation: All available memory selectors are being used by the system or by previously 
loaded device drivers. 


Action: Remove optional or unneeded device drivers from the CONFIG.SYS file. 
Then try again. If the problem persists, contact your Novell Authorized 
Reseller. 
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REQ1038: The program cannot allocate memory for the error message buffer. 


Explanation: 


Action: 


All available system memory is in use by the system. The Requester cannot 
load properly. 


Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ1039: The Requester could not send to NetWare server <number> as <number>. 


Explanation: 


Action: 


The Requester waits for a response from the server after each request. If the 
server does not respond within a certain amount of time, the Requester times 
out. 


Make sure that the server is still running and functioning properly. Also make 
sure that all routers between the workstation and the server are still running. 
If the problem persists, contact your Novell Authorized Reseller. 


REQ1040: The Requester timed out waiting for reply from server <number>. 


Explanation: 


Action: 


The Requester waits for a response from the server after each request. If the 
server does not respond within a certain amount of time, the Requester times 
out. 


Make sure that the server is still running and functioning properly. Also make 
sure that all routers between the workstation and the server are still running. 
If the problem persists, contact your Novell Authorized Reseller. 


REQ1041: Server <number> did not respond to a request. 


Explanation: 


Action: 


The Requester waits for a response from the server after each request. If the 
server does not respond within a certain amount of time, the Requester times 
out. This error can also occur if the server responds with an unexpected 
response. 


Make sure that the server is still running and functioning properly. Also make 
sure that all routers between the workstation and the server are still running. 
If the problem persists, contact your Novell Authorized Reseller. 
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REQ1042: Connection to NetWare server <number> as <number> is now invalid. 


Explanation: 


Action: 


The Requester waits for a response from the server after each request. If the 
server does not respond within a certain amount of time, the Requester times 
out. 


Make sure that the server is still running and functioning properly. Also make 
sure that all routers between the workstation and the server are still running. 
If the problem persists, contact your Novell Authorized Reseller. 


REQ1043: Routing to NetWare server <number> has been disrupted. 


Explanation: 


Action: 


The network route to the server has been disrupted. 


Make sure that the server is still running and functioning properly. Also make 
sure that all routers between the workstation and the server are still running. 
If the problem persists, contact your Novell Authorized Reseller. 


REQ1045: Routing to NetWare server <number> has been disrupted. 


Explanation: 


Action: 


The network route to the server has been disrupted. 


Make sure that the server is still running and functioning properly. Also make 
sure that all routers between the workstation and the server are still running. 
If the problem persists, contact your Novell Authorized Reseller. 


REQ1106: The SPDaemon cannot get the SPX version. Error: <code>. 


Explanation: 


Action: 


The SpxGetVersion call failed. This may be an internal program error. 


Make sure that the SPX.SYS driver has been properly entered in the 
CONFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated. Check for a mismatch 
of driver versions. If the problem persists, contact your Novell Authorized 
Reseller. 


REQ1107: The SPX driver and the SPX daemon are incompatible versions. 


Explanation: 


Action: 


The SPX.SYS driver and SPDAEMON.EXE versions may not match. 


Make sure that the client SPX.SYS driver and SPDAEMON.EXE are 
compatible versions. If the problem persists, contact your Novell Authorized 
Reseller. 
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REQ1108: The SPX driver entry cannot be obtained. Error: <code>. 


Explanation: The SPDaemon could not get a handle to the SPX.SYS driver. This may be an 
internal program error. 


Action: Make sure that the client SPX.SYS driver and SPDAEMON.EXE versions are 
compatible. If the problem persists, contact your Novell Authorized Reseller. 


REQ1109: The SPX daemon is already loaded. Error: <code>. 


Explanation: The SPDAEMON.EXE has already registered with the SPX.SYS driver, 
which means it is already loaded. 


Action: Make sure that the daemon SPDAEMON.EXE has not been entered in the 
CONFIG.SYS file more than once. 


REQ1110: The daemon cannot register with the SPX driver. Error: <code>. 
Explanation: The SPDaemon cannot communicate with the SPX.SYS driver. 


Action: Make sure that the SPX.SYS file has been properly entered in the 
CONFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated. Check for a mismatch 
of driver versions. If the problem persists, contact your Novell Authorized 
Reseller. 


REQ1111: The SPX device handle cannot be closed. Error: <code>. 


Explanation: The SPDeamon cannot close the device handle. This may be an internal 
program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1112: The SPDaemon cannot wait on semaphore. Error: <code>. 
Explanation: A DosSemSetWait call failed. This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1113: System information segments cannot be obtained. Error: <code>. 
Explanation: The DosGetInfoSeg call failed. This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 
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REQ1114: Priority for the lock thread cannot be set. Error: <code>. 
Explanation: The DosSetPrty call failed. This may be internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1115: The SPX driver cannot be accessed. Error: <code>. 
Explanation: The SPDaemon was not able to access SPX.SYS through the call gate. 


Action: Make sure that the SPX.SYS driver has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated. Also check for a 
mismatch of driver versions; then try again. If the problem persists, contact 
your Novell Authorized Reseller. 


REQ1116: Priority for an AES thread cannot be set. Error: <code>. 
Explanation: The DosSetPrty call failed. This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1117: Priority for a watchdog thread cannot be set. Error: <code>. 
Explanation: The DosSetPrty call failed. This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1118: Priority for a session thread cannot be set. Error: <code>. 
Explanation: The DosSetPrty call failed. This may be an internal program error. 


Action: Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1119: The SPXCALLS.DLL cannot register with the SPX driver. 
Explanation: The SPXCALLS.DLL cannot communicate with the SPX.SYS driver. 


Action: Check to see if the SPX.SYS driver has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated. Check for a mismatch 
of driver versions; then try again. If the problem persists, contact your Novell 
Authorized Reseller. 
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REQ1205: The driver cannot initialize the CGroup Data variables. 


Explanation: Normally, key data variable are stored in the driver's CGroup for easy and 
reliable access. However, in this instance the variables could not be initialized 
due to a memory-related error. 


Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ1206: The driver cannot configure SPX. 


Explanation: The driver in conjunction with the NWCONFIG.DLL failed to parse the 
NET.CFG file for the SPX parameters. 


Action: | Make sure the format of the NET.CFG file is correct. 


REQ1207: The driver failed to get support hooks from the LSL or IPX. 


Explanation: SPX could not open or communicate with either the LINKSUP_ (LSL.SYS) 
or the IPX_ (IPX.SYS) drivers. The most likely cause of this error is that one 
or both of these drivers has been improperly installed. 


Action: Make sure that the device drivers LSL.SYS and IPX.SYS have been properly 
entered in the CONFIG.SYS file. If so, check the messages displayed by the 
driver for any errors or warnings, and correct the problems indicated. Check 
for a mismatch of driver versions; then try again. If the problem persists, 
contact your Novell Authorized Reseller. 


REQ1208: The OS/2 version cannot be obtained; OS/2 v2.0 is assumed. 


Explanation: The DosGetVersion call failed (an internal program error), or the OS\2 version 
currently running is not v2.0 or later. 


Action: Make sure that OS/2 and the SPX.SYS driver are compatible versions. If this 
is not the problem, contact your Novell Authorized Reseller. 
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REQ1209: The driver cannot get OS/2 DOS variables. 


Explanation: 


Action: 


The SPX.SYS driver could not obtain either the system or local information 
segment. This may be an internal program error. 


Try again. If the problem persists, contact your Novell Authorized Reseller. 


REQ1210: The driver cannot initialize the SPX call gate. 


Explanation: 


Action: 


The SPX.SYS driver could not register a call gate with the LSL.SYS driver. 


Make sure that the LSL.SYS driver has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated. Check for a mismatch 
of driver versions; then try again. If the problem persists, contact your Novell 
Authorized Reseller. 


REQ1211: The driver cannot allocate memory for SPX use. 


Explanation: 


Action: 


The system does not have enough memory to run SPX. 


Try adding RAM, reducing your configuration options in the CONFIG.SYS 
file (for example, reducing the size of DIRCACHE), removing optional 
device drivers from the CONFIG.SYS file, and freeing up some hard disk 
space by deleting unnecessary programs. If you are using multiple disk 
partitions, consider moving the OS/2 swapper file to a larger partition. Disk 
compression utilities may also be available that can help resolve this problem. 
After completing these actions, shut down OS/2; then reboot the system. If the 
problem persists, contact your Novell Authorized Reseller. 


REQ1301: The application cannot initialize named pipes. 


Explanation: 


Action: 


The application could not open or communicate with the NMPIPE.SYS 
driver. Most likely, the NMPIPE.SYS driver is not entered in the 
COMNFIG.SYS file. 


Make sure that the NMPIPE.SYS driver has been properly entered in the 
COMNFIG.SYS file. If so, check the messages displayed by the driver for any 
errors or warnings, and correct the problems indicated. If the problem persists, 
contact your Novell Authorized Reseller. 
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NET.CFG Options Reference 


Topic 





“Using the NET.CFG Reference Pages” on page 202 
“Daemon Configuration” on page 203 
“DisplayHardErrors” on page 204 
“Link Driver” on page 205 

“Link Support” on page 216 

“Named Pipes” on page 218 
“NetWare NetBIOS” on page 221 
“NetWare Requester” on page 227 
“Protocol ODINSUP” on page 234 
“Protocol Stack IPX” on page 236 
“Protocol Stack SPX” on page 238 


“Token-Ring Source-Route Driver” on page 242 


This appendix contains an alphabetical listing of all NET.CFG options. For 
instructions on how to edit the NET.CFG file, format requirements, and 
reasons to configure, see Chapter 4, “How to Configure Your Workstation,” 


on page 37. 


All the information in this appendix is also found online in the NetWare 


Requester installation and configuration program. 
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Using the NET.CFG Reference Pages 


Figure 51 explains how to read the NET.CFG reference pages in this chapter. 


Figure 51 Format of NET.CFG reference pages 


Link support mm 
PP Description 
Use this option to adjust the number and size of communication ; 
buffers used by the Requester. of option 


1 Square brackets 
mean the 
parameter 
Settings is optional 














Replace words in 
italics with 





link support 
buffers count [buffer size] è 


specific values 








Setting name 





buffers count [buffer_size] 


Use this setting to specify how many and what size Description of 
communication buffers the Requester can use. setting 
What to type Usage Usage Replace count with a number of buffers 


greater than one. 








Replace buffer_size with a number of bytes greater 
than 576. 






Defaults Defaults Count: 20 buffers 
Buffer_size: 1130 bytes 


Examples For an Ethernet configuration: Example of use 


link support 
buffers 20 1514 


Special 
considerations 





1. Unless your site has a particularly unique and complex network 
setup, you will probably never need to use the performance 
tuning options. The defaults have already been set to produce 
maximum performance in almost all cases. 


when using the 
option 
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Daemon Configuration 


Use this option to control the length of time network-related error messages 
stay on your screen. This option controls only pop-up and broadcast messages. 


NOTE: Pop-up and broadcast messages appear in a small box on your screen and 
prompt you to "Press <Esc> to continue .. ." 


Setting 


message timeout 





Syntax daemon configuration 
message timeout number 


Replace number with a number of milliseconds that you want 
pop-up and broadcast messages to display on your screen 
before disappearing. 


Replace number with 0 (zero) to prevent pop-up and 
broadcast messages from displaying at all. 


If you leave this line out of your NET.CFG, pop-ups and 
broadcast messages are displayed until you press <Esc>. 








Default Pop-up and broadcast messages display until you press 
<Esc>. 

Example To prevent pop-up and broadcast messages from 
displaying: 


daemon configuration 
message timeout 0 
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DisplayHardErrors 


Use this option to keep programs running without interaction when a hard 
error is displayed. With this option set, hard errors are automatically returned 
to the program that caused them rather than displayed to you for further 
interaction. 


This option is useful for sites with unattended workstations. Be careful about 
using it in other environments as you might turn off important messages. 


NOTE: Hard errors display on a full screen and prompt you to choose among 
several actions. These error messages cause background processes to suspend 
until you respond to the message. 


displayharderrors no 











Syntax Type displayharderrors no to keep error messages from 
displaying. 
To display error messages, leave this line out of your NET.CFG 
file. 

Default Error messages are displayed. 

Example To prevent hard error messages from displaying: 


displayharderrors no 
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Link Driver 


Syntax 


Option 


link driver 


Use this option to specify the hardware configuration of the LAN drivers for 
each network board in your workstation. 


Use this option only if the network boards are not using the default settings. 
The settings you specify with this option should match the hardware settings 
for your boards. 


NOTE: If you have more than one network board in your workstation, put this 
option in your NET.CFG file for each board. 


link driver name 
dma [index] channel 
frame name 
int [index] irq 
mem [index] starting address [size] 
node address number 
port [index] starting port [number] 
protocol name id frame 
slot number 


Use this option to specify the name of the LAN driver whose defaults you 
want to modify. 





Syntax link driver name 


Replace name with the name of the driver. Table 16 on page 206 
lists some network boards and their driver names. 


Default None. 


Example To configure an IBM Token-Ring PC driver, type the following 
with any settings from the following pages: 


link driver token 
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Table 16 List of network boards and drivers 


Driver name 


Network board 





NE2 
NE2_ 32 
NE1000 
NE2000 
TOKEN 
LANSUP 
ODINSUP 
3C501 
3C503 
3C505 
3C523 
PCN2 


PCN2L 


Novell Ethernet NE/2 

Novell Ethernet NE/2-32 

Novell Ethernet NE1000 

Novell Ethernet NE2000 

IBM Token-Ring 

Boards using NDIS drivers 

IBM Token-Ring and Ethernet Communications Manager 
3Com EtherLink series 501 

3Com EtherLink series 503 

3Com EtherLink series 505 

3Com EtherLink/MC series 

IBM PC Network II and II/A (older Novell frame format) 


IBM PC Network II and II/A (newer IBM frame format) 


NOTE: The PCN2 and PCN2L drivers cannot be used in the same workstation. 
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Settings 


DMA 


Use this setting to specify which direct memory access (DMA) channel the 
network board uses. 





Syntax link driver name 
dma [index] channel 


Replace index with either #1 or #2 (optional). 


The driver configuration table for each board can store the DMA 
channel number on either of two lines. The lines are labeled #1 
and #2. 


Replace channel with the number of the DMA channel used by the 
board. 


The channel numbers for different network boards are recorded in 
the documentation from the board manufacturers. 





Defaults Index: #1 
Most boards use this default. 
Channel: Set by the driver. See the documentation for the board. 


You can't change the DMA setting on 3Com Etherlink 503 
boards, and you do not need to change it on 3Com Etherlink 505 
boards. You can change the DMA setting on 3Com Etherlink 523 
boards. 





Example To set the DMA channel for a 3Com Etherlink 505 board: 


link driver 3C505 
dma 7 





frame 


Use this setting to specify which frame type the driver for your network board 
uses. 


Use this setting only for boards that support more than one frame type or if 
you want multiple networks (separate network addresses) to share the same 
network board and cabling. 
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The frame type transmitted by the workstation should match the type of 
packets being transmitted by the servers on your network. 





Syntax link driver name 


frame name 


Replace name with the name of the frame type. Table 17 lists 
common frame types and the network board drivers that support 
each type. This list is not comprehensive. 





Default Set by the driver. See the documentation for the board. 





Examples To specify the Ethernet_802.2 frame type for an NE2000 board: 


link driver ne2000 


frame ethernet_802.2 


To specify the Ethernet_802.2 and Ethernet_802.3 frame types 
for an NE1000 board (for two logical networks): 


link driver ne1000 


frame ethernet_802.2 
frame ethernet_802.3 





Table 17 List of frame types and drivers 


Frame type 


Network board driver 





Ethernet_802.3 


Ethernet_802.2 


Ethernet_ll 


Ethernet_SNAP 


Token-Ring 
Token-Ring_SNAP 


IBM_pcn2_802.2 


NE1000, NE2000, NE2100, NE2, NE2_ 32, 3C501, 
3C503, 3C505, 30523, EXOS205, EXOS215, 
ODINSUP 


NE1000, NE2000, NE2100, NE2, NE2_ 32, 3C501, 
3C503, EXOS205, EXOS215, ODINSUP, LANSUP 


NE1000, NE2000, NE2100, NE2, NE2_ 32, 3C501, 
3C503, 3C505, 3C523, EXOS205, EXOS215, 
ODINSUP 


NE1000, NE2000, NE2100, NE2, NE2_ 32, 3C501, 
3C503, EXOS205, EXOS215, ODINSUP, LANSUP 


ODINSUP, TOKEN, LANSUP 
ODINSUP, TOKEN, LANSUP 


PCN2, PCN2L, LANSUP 
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Frame type Network board driver 





IBM_pcn2_snap PCN2, PCN2L, LANSUP 


Novell_rx-net TRXNET, TRXNET2 


If you are using the ODINSUP driver, you must enable multiple frame types 
for each driver. For Ethernet, enable Ethernet_802.3, Ethernet I, 
Ethernet_802.2, and Ethernet_SNAP. 


For Token-Ring, enable Token-Ring and Token-Ring SNAP. For more 
information about ODINSUP, see Chapter 8, “Sharing a Network Board with 
IBM Software,” on page 73. 


You can specify more than one frame type statement for a single driver. For 
example, you can specify that an Ethernet NE2000 board can use both 
Ethernet_802.2 and Ethernet_802.3 frame types. 802.2 is the type of 
communications sent on one network, and 802.3 is the type of communication 
sent on the other network. 


You can use up to four frame types for one set of Ethernet cabling. You can 
use either four network boards each with one frame type defined, or you can 
use one network board with four frames defined, or any similar combination. 


For Token-Ring cabling, two frames types are the maximum allowed. 


The default frame type for Ethernet drivers has changed to Ethernet_802.2. 
This may conflict with the frame type used on your network. See “Specifying 
Frame Types for a Driver” on page 48 for more information about specifying 
frame type. 
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int 


Use this setting to specify which interrupt line (IRQ) the network board uses 
to communicate with the driver. 





Syntax 


link driver name 
int [index] irq 


Replace index with either #1 or #2 (optional). 


The driver configuration table for each board can store the interrupt 
line number on either of two lines in the table. The lines are labeled 
#1 and #2. 


Replace irq with the number of the interrupt line used by the board. 


To determine the interrupt line number for your network board, see 
the documentation for the board. 





Defaults 


Index: #1 
IRQ: Set by the driver. See the documentation for the board. 





Example 


To set the interrupt line for an NE2000 board: 


link driver ne2000 
int 3 





Before changing the interrupt setting for your board, be sure you know what 
interrupt settings are used on other hardware (such as monitors) that you are 
using. For example, interrupts 2 and 9-15 are usually reserved, so don't use 
those numbers (especially 2) for your network board. We recommend using 3, 
5, or 7 for most network boards. 


If you are using a PS/2 computer on a Token-Ring network, do not 
autoconfigure with the Reference diskette. Doing so may cause problems. 


210 NetWare Workstation for OS/2 v2.01 


mem 


Use this setting to specify what range of memory can be used by the driver. 





Syntax 


link driver name 
mem [index] starting address size 


Replace index with either #1 or #2 (optional). 


The driver configuration table for each board can store the 
memory range on either of two lines in the table. The lines are 
labeled #1 and #2. 


Replace starting_address with a hexadecimal memory address 
that begins the range. This address must be five digits and the 
same as the address designated for the board by the 
manufacturer. (See the documentation for the board). 


Replace size with a hexadecimal number of paragraphs in the 
memory range (optional). 





Defaults 


Index: #1 


Starting_address: Set by the driver. See the documentation for 
the board. 


Size: Set by the driver. See the documentation for the board. 





Example 


To set the memory range for a Token-Ring board: 


link driver token 
mem cc000 200 





Assign each board a unique memory range. Be sure that you don't assign a 
range that is already being used by other hardware. (VGA monitors commonly 
use C6FFF and XVGA monitors commonly use CFFFF.) 
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node address 


Use this setting to change the node address of a network board. This setting 
can only be used with network boards that allow you to override the preset 











address. 
Syntax link driver name 
node address number 

Replace number with a hexadecimal address. You can specify the 
address with either the least significant bit first (Isb format) or the 
most significant bit first (msb format). 

Default The address preset on the board. 

Example To change the address for board that uses the ODINSUP driver: 


link driver odinsup 
node address 02608c861759 





port 


Use this setting to specify which range of I/O ports the network board uses. 





Syntax link driver name 
port [index] starting port [number] 


Replace index with either #1 or #2 (optional). 


The driver configuration table for each board can store information 
about ports on either of two lines in the table. The lines are labeled 
#1 and #2. 


Replace starting_port with a hexadecimal port number that begins 
the range. We recommend not using 2EO and 2FO since these 
port numbers are normally used by ARCnet for other functions. 


Replace number with the hexadecimal number of bytes in the 
range (optional). 





Defaults Index: #1 


Starting_port: Set by the driver. See the documentation for the 
board. 


Number: Set by the driver. See the documentation for the board. 
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Example To set the memory range for board that uses the NE2000 driver: 


link driver ne2000 
port 300 





protocol 


Use this setting to allow LAN drivers to use protocols that have different 
frame types. 





Syntax link driver name 
protocol name ID frame 


Replace name with the acronym of an ODI-compliant protocol. 


Some common protocols are: 
ARP 
IP 
IPX (the NetWare protocol) 
RARP 


Replace /D with the hexadecimal number of the protocol that goes 
with the frame type you specify. Table 18 on page 214 shows 
common protocols with some frame types and hexadecimal 
numbers they support. 


Replace frame with the name of the frame type used with the 
protocol. Table 18 on page 214 lists some common frame types. 





Defaults Name: IPX 
ID: 0 


Frame: Ethernet_802.3 





Example To specify the ARP protocol for an Ethernet II frame: 


link driver NE2000 
protocol arp 806 ethernet ii 





NET.CFG Options Reference 213 


Table 18 List of protocols, frame types, and hexadecimal ID numbers 














Protocol Frame type Hex number 
IPX Ethernet_802.3 0 
Ethernet_802.2 e0 
Token-Ring e0 
IBM_PCN2_ 802.2 e0 
Ethernet_ll 8137 
Ethernet_SNAP 8137 
Token-Ring_SNAP 8137 
IBM_PCN2_SNAP 8137 
Novell_RX-Net fa 
IP Ethernet_ll 800 
Ethernet_SNAP 800 
Token-Ring_SNAP 800 
Novell_RX-Net d4 
ARP Ethernet_ll 806 
Ethernet_SNAP 806 
Token-Ring_SNAP 806 
Novell_RX-Net d5 
RARP _ Ethernet_ll 8035 
Ethernet_SNAP 8035 
Token-Ring_SNAP 8035 
Novell_ RX-Net d6 
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slot 


Use this setting to tell the Requester which expansion slot an EISA or 
MicroChannel board is using. 


EISA and Micro Channel boards are self-configuring, and the Requester can 
obtain all Link Driver information from the board itself. You have to tell the 
Requester which slot the board is using or, if you only have one board of a 
particular type, tell the Requester to scan all slots until it finds that board. . 





Syntax link driver name 
slot number 


Replace number with the number of the expansion slot the board 
is using or a question mark to tell Requester to scan all slots. 





Default Slot ? 





Example To automatically configure the drivers for an NE/2 board in slot 4 
and an NE/2 board in slot 2: 


link driver ne2 
slot 4 


link driver ne2 
slot 2 


This slot setting is the only Link Driver hardware-related setting 
you need to specify in this case. 


To scan the slots for a Novell Ethernet NE/2 board: 


link driver ne2 
slot ? 
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Link Support 


Use this option to adjust the number and size of communication buffers used 
by the Requester. 


Syntax 


link support 
buffers number [buffer size] 


Settings 


buffers 





Syntax Replace number with a number of buffers greater than 1. 
Replace buffer_size with a number of bytes greater than 576. 


The Requester cannot use more than 64 KB of memory for 
communication buffers. Header information takes 5 KB. This 
means that the buffer number multiplied by the buffer size (plus 
the header information) cannot be greater than 65,536 bytes. 
For example, 20 buffers multiplied by 1514 bytes equals 30,280 
bytes. 





Defaults Number: 20 buffers 
Buffer_size: 1514 bytes 





Examples For an Ethernet configuration: 


link support 
buffers 15 2800 


For a Token-Ring configuration: 


link support 
buffers 14 4210 





Notes 


1. Increasing efficiency. For most efficient communication, your link 
support buffer size should be the same size as the packets that your 
workstation will receive over the network. You may want to set the link 
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support buffer size equal to the largest buffer size that the network boards 
in your workstation will support. 


. Using the TRXNET.SYS driver. If your workstation experiences 
performance problems running with TRXNET.SYS, you may need to 
reconfigure the number and size of link support buffers allowed. Set the 
following values: 


link support 
buffers 15 4202 


TRXNET.SYS only supports SMC100, 110, and 120 cards. 
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Named Pipes 


Use this option to manage Named Pipes sessions. 


Syntax 
named pipes 
client sessions number 
server sessions number 
service threads number 
Settings 


client sessions 


Use this setting to specify the maximum number of connections a workstation 
can establish with all Named Pipes servers. 





Syntax named pipes 
client sessions number 


Replace number with a number from 3 to 128. 


You need at least one client session for each connection from an 
OS/2 application to a Named Pipes server. 





Default 16 sessions. 


The default is usually adequate, except with applications that 
use many Named Pipes. 





Example To allow each client thirty sessions: 


named pipes 
client sessions 30 
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server sessions 


Use this setting to specify the maximum number of connections a Named 
Pipes server can support with all Named Pipes clients at any one time. 





Syntax named pipes 
server sessions number 


Replace number with a number greater than 2. 


Novell's Named Pipes support is designed to handle more than 
1,000 server sessions; however, because of OS/2 requirements, 
the practical upper limit is much lower (around 400). 


You must have one more SPX session than you have Named 
Pipes server and client sessions combined (see “Protocol Stack 
SPX” on page 238). 





Default 32 sessions. 





Example To allow each server three hundred sessions: 


named pipes 
server sessions 300 
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service threads 


Use this setting to specify the number of threads the Named Pipes server can 
use to handle requests from all clients. 





Syntax named pipes 
service threads number 


Replace number with a number from 1 to 32. 


If the client application uses blocking pipes, increase this default. 
If the client application uses non-blocking pipes, use the default 
value for better performance. SQL Server does not use blocking 








pipes. 
Default 3 threads 
Example To increase the number of threads a Named Pipes server can 


use to twenty: 


named pipes 
service threads 20 





NOTE: For an OS/2 workstation to function as a Named Pipes server or client, you 
must have selected Named Pipes when you installed the Requester on that 
workstation. See “Installing Named Pipes for OS/2” on page 116. 
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NetWare NetBIOS 


Use this option to manage NetBIOS names and sessions or to affect the 
internal memory allocation for NetBIOS. 


Table 19 Categories of NetWare NetBIOS settings 





Purpose Setting 





Name management “broadcast count” on page 223 
“broadcast delay” on page 223 
“internet” on page 224 


“names” on page 225 





Session creation “retry count” on page 225 
“retry delay” on page 226 


“sessions” on page 226 





Session management “abort timeout, listen timeout, verify 
timeout” on page 222 





Command management “commands” on page 224 





Syntax 


netware netbios 
abort timeout number 
broadcast count number 
broadcast delay number 
commands number 
internet [on|off] 
listen timeout number 
names number 
retry count number 
retry delay number 
sessions number 
verify timeout number 
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Settings 


abort timeout, listen timeout, verify timeout 
Use these settings to monitor and control your NetBIOS connections. 


When NetBIOS sessions at a sending computer do not receive any 
transmissions from the receiving computer for the length of the "verify 
timeout" interval, NetBIOS sends a request-for-acknowledgment packet to the 
receiving computer. NetBIOS then waits the length of the "listen timeout" 
interval to receive a response. 


If no response is received, NetBIOS sends another packet requesting 
immediate response. NetBIOS then waits the length of the "abort timeout" 
interval to receive a response. 


If no response is received, NetBIOS terminates the session. 





Syntax netware netbios 
abort timeout number 
listen timeout number 
verify timeout number 


Abort timeout: Replace number with a number of milliseconds 
greater than 500. 


Listen timeout: Replace number with a number of milliseconds 
greater than 200. 


Verify timeout: Replace number with a number of milliseconds 
greater than 100. 


The ratio between these settings must remain the same. For 
example, if you double the Listen timeout value, you must also 
double the Abort timeout and Verify timeout values. 





Defaults Abort timeout: 30,000 milliseconds 
Listen timeout: 6,000 milliseconds 


Verify timeout: 3,000 milliseconds 
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Examples To make NetBIOS wait longer before sending a request-for 
acknowledgment packet, sending the packet requesting 
immediate response, and terminating the session: 


netware netbios 
abort timeout 45000 
listen timeout 8000 
verify timeout 4000 





broadcast count 


Use this setting to specify how many times NetBIOS broadcasts a query or 
claim for the name being used by an application. 





Syntax netware netbios 
broadcast count number 


Replace number with a number of queries greater than 1. 





Defaults With internet on: 4 times 


With internet off: 2 times 





Example To broadcast more often: 


netware netbios 
broadcast count 8 





broadcast delay 


Use this setting to specify how long NetBIOS waits between query or claim 











broadcasts. 
Syntax netware netbios 
broadcast delay number 
Replace number with a number of milliseconds greater than 100. 
Defaults With internet on: 2,000 
With internet off: 1,000 
Example To wait longer between broadcasts: 


netware netbios 
broadcast delay 3000 
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commands 


internet 


Use this setting to specify how many NetBIOS commands can be buffered in 
the NetBIOS driver at any one time. 





Syntax netware netbios 
commands number 


Replace number with a number of commands from 8 to 64. 








Default 32 commands 
Example To run an application that requires a large number of outstanding 
commands: 


netware netbios 
commands 64 





Use this setting to transmit name-claim packets to and from all stations on the 
internetwork, or to and from stations on the local network only. 


Name-claim packets are packets that attempt to establish the uniqueness of the 
name of the station on which NetBIOS is running. 





Syntax netware netbios 
internet [on|off] 


Type on or off. 





Default On 





Example To send and receive on the local network only: 


netware netbios 
internet off 
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names 


retry count 


Use this setting to specify how many names the workstation can have in its 
name table for remote stations. When you add a name to a station, the station 
broadcasts that name to all other nodes on the network. 





Syntax netware netbios 
names number 


Replace number with a number of names from 4 to 64. 


You can use a name instead of a node address to refer to a remote 








station. 
Default 24 names 
Example To allow 45 names: 


netware netbios 
names 45 





Use this setting to specify how many times NetBIOS transmits a request for 
connection or retransmits a failed communication. 





Syntax netware netbios 
retry count number 


Replace number with a number greater than 0. 





Default 20 times 





Example To retransmit 50 times: 


netware netbios 
retry count 50 
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retry delay 


Use this setting to specify how many milliseconds NetBIOS waits between 
transmissions while establishing a connection or resending a data packet. 





Syntax netware netbios 
retry delay number 


Replace number with a number of milliseconds greater than 0. 








Default 500 milliseconds 
Example To wait eight hundred milliseconds between retransmission 
attempts: 


netware netbios 
retry delay 800 





sessions 


Use this setting to specify how many simultaneous NetBIOS sessions can be 
supported by the NetBIOS driver. 





Syntax netware netbios 
sessions number 


Replace number with a number of sessions from 4 to 64. 





Default 16 sessions 





Example To allow one hundred NetBIOS sessions: 


netware netbios 
sessions 50 
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NetWare Requester 


Use this option to control network requests from your workstation to a 
NetWare server. 


Syntax 


netware requester 
cache buffers number 
directory services off 
large internet packets off 
name context context 
packet burst off 
preferred servername 
preferred tree treename 
request retries number 
sessions number 
signature level number 


Settings 


cache buffers 


Use this setting to specify how many buffers the Requester can use to cache 
data from open files. 


Cache buffers minimize read and write traffic on the network. The more 
buffers there are, the faster the Requester performs; however, more buffers use 
up more memory. 


The Requester automatically uses the maximum buffer size permitted by each 
server to which the Requester is connected. However, the Requester cannot 
use more than 64 KB of total memory for cache buffers. Therefore, if the 
buffer size is large, you may not be allowed as many buffers as you specify. 
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Syntax netware requester 
cache buffers number 


Replace number with a number of buffers from 0 to 30. 


To turn off caching, specify 0. 





Default 8 buffers 





Example To allow 15 cache buffers: 


netware requester 
cache buffers 15 





directory services off 


Use this setting to disable directory services if you are on a NetWare 2.x or 3.x 
server. This will improve speed and overall performance because the 
Requester does not have to time out to establish initial connections with a 
NetWare v4.0 server. 





Syntax netware requester 
directory services off 


Type directory services off to disable directory services. 





Default Directory services is enabled. 





Example To disable directory services: 


netware requester 
directory services off 
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large internet packets off 


Use this setting to disable large internet packets transmission. Chapter 6, 
“Improving Speed and Security,” on page 59 explains more about large 
internet packets. 





Syntax netware requester 
large internet packets off 


Type large internet packets off to turn off large packet 
transmissions. 





Default Large internet packets are transmitted. 





Example To disable large packet transmission: 


netware requester 
large internet packets off 





name context 


Use this setting to specify the workstation's name context in the directory 
services tree. Concepts explains more about name contexts. 





Syntax netware requester 
name context "context" 


Replace context with your name context in the directory tree. 





Default At the root of the tree. 





Example To specify a name context: 


netware requester 
name context "john.sales.novell us" 
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packet burst off 


Use this setting to disable the packet burst feature. “Improving Speed with 
Packet Burst” on page 59 explains more about the Packet Burst feature. 





Syntax netware requester 
packet burst off 





Default Packet burst is enabled. 





Example To disable packet burst: 


netware requester 
packet burst off 





preferred server 


Use this setting to specify which NetWare server you want your workstation 
to attach to when it first accesses the network. 


NOTE: If the server you specify is unavailable, your workstation will attach to the 
first available server. 





Syntax netware requester 
preferred server servername 


Replace servername with the name of a server. The server you 
specify should probably have the NetWare utilities for OS/2 








installed. 
Default None 
Example To attach to server FINANCE: 


netware requester 
preferred server finance 
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preferred tree 


Use this setting to specify a tree name to connect. This setting is only for sites 
with more than one directory tree. 





Syntax netware requester 
preferred tree treename 


Replace treename with the name of your tree. Tree names can 
have up to 32 characters. 





Default None. 





Example To connect to a tree named Novell: 


netware requester 
preferred tree novell 





request retries 


Use this setting to specify how many times the Requester tries to resend a 
request following a communication error. 





Syntax netware requester 
request retries number 


Replace number with a number of retries greater than 5. 





Default 20 retries 


Decrease the default if you are connected to the network over a 
modem and you do not want to waste phone time while the 
Requester keeps trying to resend packets. 





Example To decrease the number of times the Requester tries to resend 
a packet: 


netware requester 
request retries 10 





NET.CFG Options Reference 231 


sessions 


Use this setting to specify the number of connections the Requester can have 
to all servers. 





Syntax netware requester 
sessions number 


Replace number with a number of connections from 8 to 32. You 
must have at least three IPX sockets for each session you allow. 
(See “sockets” on page 237.) 





Default 8 sessions 





Example To allow more server connections: 


netware requester 
sessions 20 


You must also increase the sockets setting for the Protocol Stack 
IPX option in this case. 





signature level 


Use this setting to assign a signature level. Signature levels help determine 
security on your network. “Improving Security by Using Packet Signature” on 
page 61 explains more about signature levels. 





Syntax NetWare Requester 
signature level number 


Replace number with 0, 1, 2, or 3. 


Table 20 on page 233 describes the list of NCL Packet Signature 








levels. 
Default 1 (Workstation signs packets only if the server requests 
signing.) 
Example To prevent the workstation from signing packets: 


netware requester 
signature level 0 
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Table 20 List of NCP Packet Signature levels 








Number Explanation 
0 Workstation does not sign packets 
1 Workstation signs packets only if the server requests it (Server 


option is 2 or higher) 


2 Workstation signs packets if the server is capable of signing 
(server option is 1 or higher) 


3 Workstation signs packets and requires the server to sign 
packets (or logging in will fail) 
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Protocol ODINSUP 


Use this option to allow the NDIS protocol stack (used with Extended Services 
and LAN Services) to communicate using ODI Token-Ring or Ethernet 
drivers. 


See “Sharing a Network Board with IBM Software” on page 73 before using 
this option. 


Syntax 
protocol odinsup 
bind driver [number] 
Settings 
bind 


Use this setting to bind the ODINSUP protocol to an ODI driver. When 
ODINSUP is bound to a driver, the network board for that driver is the board 
used for transmissions to and from the network. 





Syntax protocol odinsup 
bind driver [number] 


Replace driver with a Token-Ring or Ethernet ODI driver name. 
See Table 16 on page 206 for a list of common driver names. 


Use number to bind ODINSUP to a particular occurrence of a 
board when you have two boards with the same name. Replace 
number with a number from 1 to 4. 


For example, if you have two NE2000 network boards in your 
workstation, bind ODINSUP to each board by typing a 2 for the 
second board. 


ODINSUP can be bound to a maximum of four ODI drivers. 





Default ODINSUP binds to the first Ethernet or Token-Ring board it 
locates. 
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Examples To bind ODINSUP to a single NE2000 board in your workstation: 


protocol ODINSUP 
bind ne2000 


To bind ODINSUP to both the first and the second NE2000 
boards in your workstation: 


protocol ODINSUP 
bind ne2000 
bind ne2000 2 
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Protocol Stack IPX 


Use this option to adjust IPX communication between applications and the 
LAN drivers in your workstation. 


Syntax 
protocol stack ipx 
bind name 
router mem size 
sockets number 
Settings 
bind 


Use this setting to specify the primary network board in your workstation. By 
default, the primary board is the board whose driver loads first in the 
CONFIG.SYS file. If you specify a different board with this setting, that 
default is changed. See Chapter 5, “Network Boards and Drivers,” on page 47. 





Syntax protocol stack ipx 
bind name 


Replace name with the driver name for your network board. 


Table 16 on page 206 lists common network boards. 





Default The first driver listed in your CONFIG.SYS file. 





Example To specify a 3Com Etherlink 3C503 board as primary: 


protocol stack ipx 
bind 3C503 
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router mem 


Use this setting to specify how many bytes in the router memory pool are 
allocated for routing requests to the network. 





Syntax protocol stack ipx 
router mem size 


Replace size with a number of bytes. 





Default 450 bytes 


Since a size of 450 bytes accommodates up to 15 network 
boards per workstation, you should not need to increase this 
default. 





Example To increase the default: 


protocol stack ipx 
router mem 500 





sockets 


Use this setting to specify how many sockets IPX can open at your 
workstation. 





Syntax protocol stack ipx 
sockets number 


Replace number with a number of sockets between 9 and 128. If 
you are running IPX with the Requester, do not set this value 
below 32. 


You need three sockets per server connection. The default of 64 
works for the default number of server connections (see 
“sessions” on page 232), 





Default 64 sockets 





Example To set the socket limit for a workstation connected to several 
servers that is running Named Pipes and applications that 
require sockets: 


protocol stack ipx 
sockets 128 
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Protocol Stack SPX 


Use this option to adjust the number and characteristics of SPX connections 
between your workstation and other computers. 


Syntax 


protocol stack spx 
abort timeout number 
listen timeout number 
retry count number 
send timeout number 
sessions number 
verify timeout number 


Settings 


abort timeout, listen timeout, verify timeout 
Use these settings to monitor and control SPX connections. 


When SPX sessions at a sending computer do not receive transmissions from 
the receiving computer for the length of the "verify timeout" interval, SPX 
sends a keep-connection-alive packet to the receiving computer. SPX then 
waits the length of the "listen timeout" interval to receive a response. 


If no response is received, SPX sends another packet requesting immediate 
acknowledgment. SPX then waits the length of the "abort timeout" interval to 
receive a response. 


If no response is received, SPX aborts the session. 
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Syntax protocol stack spx 
abort timeout number 
listen timeout number 
verify timeout number 


Replace number with a number of milliseconds greater than 10. 


The ratio between these settings must remain the same. For 
example, if you double the Listen timeout value, you must also 
double the Abort timeout and Verify timeout values. 


If the machine you are setting up will be a Named Pipes server, 
double the default timeout values. 





Default Abort timeout: 30,000 milliseconds 
Listen timeout: 6,000 milliseconds 


Verify timeout: 3,000 milliseconds 





Example To make SPX wait longer before sending a keep-connection- 
alive packet, sending the packet requesting immediate 
response, or aborting the session: 


protocol stack spx 
abort timeout 40000 
listen timeout 8000 
verify timeout 4000 
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retry count 


Use this setting to specify the number of times your workstation will resend 
packets that weren't acknowledged by the receiving computer the first time 
they were sent 


NOTE: Some applications may set the "retry count" value. In these cases, the 
application-set value is used and the NET.CFG value is ignored. 





Syntax protocol stack spx 
retry count number 


Replace number with a number of retries from 1 to 255. 


If your network traffic is heavy or if you are transmitting across 
routers, you may want to increase the default. 





Default 15 retries 





Example To increase the number of times packets are resent: 


protocol stack spx 
retry count 30 





send timeout 


Use this setting to specify how long SPX waits between attempts to send 
packets across the network. 





Syntax protocol stack spx 
send timeout number 


Replace number with a number of milliseconds greater than 500. 


This default works well in almost all cases. Increase the default if 
you are using network management products with a very large 
network and you encounter many SPX connection errors. 


You may also want to increase the default for a Named Pipes client 
that is operating faster than the Named Pipes server to which it is 
connected. 





Default A continually calculated value based on the time it takes SPX to 
get a response from the server. 





Example To increase the wait between sends: 


protocol stack spx 
send timeout 5600 
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sessions 


Use this setting to specify how many SPX connections can be open 
simultaneously. 





Syntax protocol stack spx 
sessions number 


Replace number with a number of SPX connections greater than 
8. Numbers higher than 1,000 may not work in all circumstances. 


If you run Named Pipes applications or other applications that use 
SPX, you may need to increase the default number of sessions. 





Default 16 sessions 





Example To increase the number of SPX sessions: 


protocol stack spx 
sessions 64 
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Token-Ring Source-Route Driver 


Syntax 


Settings 


board 


Use this option to configure the Requester for source-routing between Token- 
Ring networks that are connected with source routers. For more information 
about source routing, see Chapter 7, “Using OS/2 Workstations on a 
Token-Ring Network,” on page 67. 


NOTE: Do not use this option if your Token-Ring networks do not use source 


routing. 


protocol route 
source route def gbr mbr nodes n board n 


Use this setting to specify the logical board (frame) of a particular type that is 
performing source routing. 





Syntax 


protocol route 
source route board n 


Replace n with a logical board (frame) number from 1 to 16. 


For example, if a workstation has more than one frame type listed 
in the Link Driver option, by default only the first listed frame is 
source routed. To enable source routing on the second or other 
frames, you must explicitly specify the second frame as logical 
board 2. 





Default 


1 





Example 


To specify that logical board 2, the Token-Ring_SNAP frame, will 
also be source routed: 


link driver token 
frame token-ring 
frame token-ring_ snap 


protocol route 
source route board 1 
source route board 2 
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DEF 


Use this setting (default frame) to prevent frames that have unknown 
destination addresses from being sent across Single Route IBM bridges. 


+ If this setting is specified, these frames are forwarded as All Routes 
Broadcast frames. 


+ If this setting is not specified, all frames that have addresses not in the 
workstation's Source Routing table are forwarded as Single Route 
Broadcast frames. 


+ If ROUTE.SYS has already been configured with the DEF setting, 
reloading ROUTE.SYS with this setting broadcasts all subsequent Single 
Route Broadcast frames as All Routes Broadcast frames. 





Syntax protocol route 
source route def 


Type DEF to broadcast on all routes. Omit DEF to broadcast on a 
single route only. 





Default DEF is omitted (single-route broadcast only) 


Change this default when you are unsure of the stability of one 
or more routes in the network. Be aware that using DEF will 
substantially increase network traffic, especially on large, 
redundant ring networks. 





Example To broadcast on all routes: 


protocol route 
source route def 
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GBR 


Use this setting (general broadcast) to specify that all General BRoadcast 
frames are to be sent as All Routes Broadcast frames 





Syntax protocol route 
source route gbr 


Type GBR to broadcast to all destinations, on all rings, by all routes. 
Omit GBR to broadcast to all destinations, on all rings, by a single 
route. 


Change the default when you want to ensure successful 
transmission across all possible routes. If ROUTE has already 
been configured with this setting, reconfiguring ROUTE with this 
setting broadcasts all subsequent General Broadcast frames as 
All Routes Broadcast frames. 





Default GBR is omitted (single-route broadcast only) 





Example To broadcast to all destinations, on all rings, by all routes: 


protocol route 
source route gbr 





MBR 


Use this setting (multicast) to specify that all Multicast Broadcast frames are 
to be sent as All Routes Broadcast frames. 





Syntax protocol route 
source route mbr 


Type MBR to transmit multicast frames simultaneously to a group 
of destinations by all possible routes. Omit MBR to transmit 
multicast frames by a single route. 





Default MBR is omitted (transmit by single route only) 


If ROUTE has already been configured with the MBR setting, 
reconfiguring ROUTE with this parameter broadcasts all 
subsequent Multicast Broadcast frames as All Routes Broadcast 
frames. 





Example To broadcast multicast frames simultaneously: 


protocol route 
source route mbr 
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nodes 


Use this setting to specify the number of table entries in the source-routing 
table. 





Syntax protocol route 


source route nodes n 


Replace n with a number of table entries from 8 to 255. If you type 
a number less than 8, 8 will be used. 





Default 16 entries 





Example To allow twenty-four entries in the source-routing table: 


protocol route 
source route nodes 24 
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Architecture Diagrams 


These diagrams provide a technical overview of the NetWare Requester for 
OS/2 v2.01. They can help you understand what components are used for the 
various functions the Requester performs (for example, which components are 
used to support Named Pipes). 


Specifically, the diagrams illustrate: 
+ The major functions of the Requester components 
¢ The different components of the Requester 
¢ The relationships between components 


NOTE: You do not need to manually load the components shown in the diagrams. 
Select the settings you want in the Requester installation program, and the correct 
components will be loaded. To change the settings later, simply run the installation 
program again. 





Topics and architecture diagrams 





“NetWare Requests from OS/2 Sessions” on page 248 
“NetWare Core Protocol requests” on page 249 


“File system requests” on page 250 





“Protocol Requests from OS/2 Sessions” on page 251 
“IPX-only requests” on page 251 
“SPX requests” on page 252 
“Named Pipes server requests” on page 253 


“Named Pipes client requests” on page 254 
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Topics and architecture diagrams 





“NetBIOS Submit requests using only Novell NetBIOS driver” on page 256 


“NetBIOS Submit requests using only Novell NetBIOS driver with Extended Services 
loaded” on page 257 


“NetBIOS Submit requests using either Novell or IBM NetBIOS driver with LAN Services 
loaded” on page 258 


“NB30 NetBIOS requests using either Novell or IBM NetBIOS driver with Extended 
Services loaded” on page 259 





“NetWare Requests from DOS/Windows Sessions” on page 259 
“DOS/Windows NetWare Core Protocol requests” on page 260 


“DOS/Windows file system requests” on page 261 





“Protocol Requests from DOS/Windows Sessions” on page 262 
“DOS/Windows SPX- or IPX-only requests” on page 262 
“DOS/Windows Named Pipes client requests” on page 263 
“DOS/Windows SQL client "Get Server" requests” on page 264 
“DOS and Windows NetBIOS requests” on page 265 


“NetBIOS Submit requests using only Novell NetBIOS driver with Extended Services 
loaded” on page 257 





“Sharing a Network Board” on page 266 


“NetWare Requester and IBM software using ODINSUP to share a network board” on 
page 267 


“NetWare Requester and IBM software usingLANSUP to share a network board” on page 
268 


NetWare Requests from OS/2 Sessions 
NetWare Core Protocol Requests 


NetWare Core Protocol requests go directly to the NetWare server without 
going through OS/2. Some of the NetWare utilities issue this kind of request. 


248 NetWare Workstation for OS/2 v2.01 


These requests are usually accompanied by file system requests, shown in 
Figure 53 on page 250. 


Figure 52 NetWare Core Protocol requests 


OS/2 application 


| NWDAEMON 


NWCALLS or NWNET 












Ring 3 














Ring 0 


NWREQ 















ODI driver 
Network board 


to the 
NetWare server 





Architecture Diagrams 249 


File System Requests 


File system requests are handled by OS/2 before being passed on to the 
NetWare Requester. Any program which manipulates files on the network 
makes this kind of request. These requests are always accompanied by 
NetWare Core Protocol requests, shown on Figure 52 on page 249. 


Figure 53 File system requests 
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Protocol Requests from OS/2 Sessions 


IPX-Only Requests 


IPX requests are issued by IPX applications, including the Requester. 


Figure 54 IPX-only requests 
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SPX Requests 


SPX requests are issued by SPX applications. Some NetWare print utilities 
and API calls use SPX. 


Figure 55 SPX requests 
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Named Pipes Server Requests 


Named Pipes server requests are made by Named Pipes distributed application 
servers. 


Figure 56 Named Pipes server requests 
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Named Pipes Client Requests 


Named Pipes client requests are issued by Named Pipes distributed 
application clients. 


Figure 57 Named Pipes client requests 
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NetBIOS Requests 


What is NetBIOS 


NetBIOS is a "device-independent" protocol that lets applications use network 
boards without knowing the specifics of how the drivers for those boards 
work. 


NetBIOS applications issue NetBIOS commands which are routed to a 
specific network board driver. That driver handles the transmission of 
NetBIOS packets over the network. 


What is the Novell NetBIOS Emulator 


Novell provides a NetBIOS emulator that allows applications running on an 
IPX-based network (such as NetWare) to communicate using NetBIOS. 


This NetBIOS emulator encapsulates NetBIOS packets inside of IPX packets. 
Then an ODI driver handles transmission of the IPX packets over the network. 
While your NetBIOS application communicates using NetBIOS commands, 
the NetBIOS emulator actually transmits IPX packets. 


The Novell NetBIOS emulator can only communicate with other emulators 
that use IPX. For example, if you have one workstation running the NetBIOS 
emulator and another workstation running IBM's NetBIOS, the two 
workstations cannot communicate. 


However, the NetBIOS emulator can run on the same OS/2 workstation as 
other NetBIOS implementations, including the NetBIOS provided with IBM 
Extended Services or LAN Services. Or, the NetBIOS emulator can run by 
itself. 


NetBIOS requests are issued by applications which use Novell NetBIOS 
emulation. If Extended Services or LAN Services is installed, requests follow 
a different path. See Figure 59 on page 257 through Figure 61 on page 259. 
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Figure 58 
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Figure 59 NetBIOS Submit requests using only Novell NetBIOS driver with Extended Services loaded 
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Figure 60 NetBIOS Submit requests using either Novell or IBM NetBIOS driver with LAN Services loaded 
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Figure 61 NB30 NetBIOS requests using either Novell or IBM NetBIOS driver with Extended Services loaded 
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NetWare Requests from DOS/Windows Sessions 


When you select "Support for Virtual DOS Sessions" in the NetWare 
Requester installation program, the installation program adds lines to the 


CONFIG.SYS 


file to load the VIPX and VSHELL components. 


The NETWARE RESOURCES and VIPX_ENABLED properties are also 
created and added to the "DOS Settings" notebook of all DOS and Windows 
icons. These properties allow you to choose global support, private support, or 
no network support for each session. 


¢ If you choose global support, VIPX and VSHELL are enabled for the 


session. 


¢ Ifyou choose private support, VIPX is enabled, VSHELL is not enabled, 
and you can manually load NETX.EXE 
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+ Ifyou don't load NETX.EXE, you receive IPX- and SPX-only support. 


+ Ifyou choose VIPX_ ENABLED OFF, then no NetWare support is 
loaded. 


VIPX must be enabled for either Global (using VSHELL) or Private (using 
NETX) sessions to work. 


Figure 62 DOS/Windows NetWare Core Protocol requests 
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Figure 63 DOS/Windows file system requests 
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Protocol Requests from DOS/Windows Sessions 


Figure 64 DOS/Windows SPX- or IPX-only requests 
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Figure 65 DOS/Windows Named Pipes client requests 
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Figure 66 DOS/Windows SQL client "Get Server" requests 
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* Windows NP applications only 


Figure 67 DOS and Windows NetBIOS requests 
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Figure 68 DOS and Windows NetBIOS requests with Extended Services loaded 
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Sharing a Network Board 


How Does ODINSUP Work? 


ODINSUP translates NDIS transmissions from Extended Services or LAN 
Services into a form that complies with the ODI drivers. ODINSUP also 
translates transmissions received from the network into a form readable by 
Extended Services and LAN Services. 


ODINSUP functions like a default protocol stack, meaning that it accepts 
requests from the Link Support Layer (LSL) that are not specifically marked 
for another registered protocol (such as IPX or TCP/IP). When it receives 
requests, ODINSUP passes them on to the NDIS protocol stack. 
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ODINSUP allows IBM's Protocol Manager (found in Extended Services and 
LAN Services) to communicate with a network board without having to be 
aware of the details of transmission on that board (such as frame type). 


Instead, the details are handled at the ODI driver level and then transmissions 
are passed on to the Link Support Layer, which in turn passes them on to the 
correct protocol stack or to ODINSUP. ODINSUP translates the request to a 
form understood by Protocol Manager. 


Chapter 8, “Sharing a Network Board with IBM Software,” on page 73 
explains more about using ODINSUP. 


ODINSUP is for using ODI drivers. LANSUP is for using NDIS drivers. 


Figure 69 NetWare Requester and IBM software using ODINSUP to share a network board 
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Figure 70 NetWare Requester and IBM software usingLANSUP to share a network board 
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